A security flaw in Google's developer documentation platform turned a routine session cookie into a potential route to remote code execution. Researcher Simon Köck found that the cookie contained the same secret Google used to sign it.

This allowed Köck to forge sessions and make the company's servers execute code without logging in. He found the issue lurking in Google's shared DevSite platform, which powers developer documentation across several domains.

The investigation began with a routine look at the platform's OAuth login flow. Köck noticed that a Flask session cookie issued by developers.google.com was roughly 1,200 bytes long, far larger than he expected for a cookie carrying a security token and a return URL.

That prompted him to inspect its contents. Flask signs session cookies but doesn't encrypt them, so anyone holding a cookie can decode its payload. Köck found a serialized Python object containing Google's OAuth client ID and client secret.

“I tried the client secret as the Flask SECRET_KEY, and the signature on the issued cookie validated against it. The signing key was stored inside the object it signs,” he wrote.

This meant anyone who recovered the secret could create a new cookie and generate a valid signature, defeating the mechanism that should have stopped users from tampering with their sessions.

The exposed secret was only half the problem. Köck found that Google's OAuth callback used Python's pickle mechanism to deserialize data supplied through the session cookie. Pickle can execute code while reconstructing objects, making it dangerous when applications process data that an attacker controls.

Köck combined the 2 weaknesses to craft a malicious cookie and send it to Google's server. To test whether the server executed his payload, he instructed Python to pause for a set number of seconds.

“The response time tracked the number in the pickle,” he wrote, showing that the server had executed the payload rather than simply accepting the forged cookie.

The shared infrastructure meant the flaw affected multiple Google developer properties, including Firebase and Android documentation.

Köck reported the issue on August 6th. Google accepted the report the next day, awarded him $90,000 on August 27, and fixed the vulnerability on October 7th, according to his timeline.

The trust trap

The Google bug highlights a recurring problem in web security where small mistakes can combine into a serious security failure. Here, an exposed credential, a poorly chosen signing key, and unsafe deserialization turned a session-management flaw into a route to server-side code execution.

A similar danger showed up in the critical React Server Components flaw disclosed in December 2025. It allowed attackers to execute code on vulnerable servers through crafted requests and put React and Next.js apps at risk.

Unsafe data handling isn't just a web token problem. We saw a similar pattern on the Hugging Face platform, where attackers hid malicious code inside machine-learning models using Python’s pickle format. Just like with Google’s DevSite, the system trusted a standard data file, only for it to execute malicious code the second it was opened.

Enterprise tech also keeps walking into the same trap. A recent Microsoft SharePoint zero-day saw attackers exploit unsafe deserialization to execute server code and hijack cryptographic keys, which gave them the ability to forge trusted sessions.

All these cases underline a basic security rule that apps must never trust client-controlled data just because it arrives through a familiar framework or from a seemingly valid session. A signature can detect tampering, but it cannot protect a system if an attacker can obtain the signing key.