- A researcher reported that a sign-in cookie on Google's developer sites contained the secret used to sign it, which allowed forged sessions.
- The forged session reached code that rebuilds a stored object, and a timed delay showed server-side code could run. Google paid $90,000 and fixed the issue.
- Ask your teams whether any signing key doubles as another credential, and whether cookies carry objects the server later trusts.
A seal is not a lock
A wax seal proves a letter was not opened. It proves nothing if the stamp is printed on the letter itself. That is close to what a security researcher reports finding on Google's developer documentation sites.
The lesson here is that a signature only protects you while the signing secret stays secret. Teams often check that a cookie is signed and stop there. The harder question is where the key lives and what else it is used for.
What the researcher reported
The researcher published a write-up at simonkoeck.com on October 12, 2026. The work began with mapping the sign-in flow that Google's developer docs sites share. Visiting the sign-in address, with no account, returned a session cookie of about 1,200 bytes. That is far more than a simple anti-forgery token and a return address need.
The researcher decoded it. Inside was a stored Python object from an OAuth library, a tool that handles "sign in with Google" flows. The object held Google's OAuth client ID and client secret in plain text. The researcher says the secret was still live at the time of writing, so it was redacted.
Next, the researcher tried that client secret as the key the web framework, Flask, uses to sign its cookies. Recomputing the signature offline with that key reproduced the cookie's own signature byte for byte. In the researcher's account, the cookie held the very secret that guarded it.
Why a leaked key becomes code execution
Flask session cookies are signed, not encrypted. Anyone holding one can read it. The signature only tells the server that the contents have not been changed.
That makes the key the whole defence. With it, the researcher could write any session contents and sign them in a way the server would accept.
The second weakness was what the server did next. When the sign-in flow returned, the server read the stored object back out of the cookie using Python's pickle format. Pickle rebuilds objects from instructions, and those instructions can name a function to call. The researcher says this is safe only if nobody else can forge a valid cookie.
Put the two together and a forged cookie could make the server call a function of the attacker's choosing. The researcher describes this as unauthenticated remote code execution. That means a stranger with no login could run code on the server.
How the claim was proved without harm
The researcher says no commands were run on Google's production systems. The proof was timing instead, using a harmless instruction that makes the server pause for a chosen number of seconds. The response time followed the number picked.
The researcher also ran controls. A cookie with one character of its signature changed was rejected. A valid signature with no matching sign-in record was refused. A valid signature with the real flow got as far as Google's token exchange. The researcher says these ruled out a slow endpoint or random delay.
One platform, many sites
The researcher says this was not a single application. It was the shared DevSite platform. The write-up reports that the secret from developers.google.com also signed sessions that other sites on the platform accepted as genuine.
That is the quiet cost of shared platforms. A shared design choice multiplies a single mistake. It also means one fix, done well, protects every site on it. The write-up ends with thanks to Google's Bug Hunters team and the DevSite engineers who investigated and fixed the issue.
The reward was rated S0 (remote code execution) in Google's tier for normal applications (T2). It was a $75,000 base with a 1.2 multiplier for exceptional report quality. The decision is dated August 27, 2026.
Questions to put to your team
This is one report about one platform. It does not show how common the pattern is. It does give leaders four clear checks, drawn from the researcher's own recommendations.
First, does any signing key double as another credential, such as an OAuth secret? Each deployment should have its own long, random key held in a server-side store.
Second, what do your cookies carry? The researcher advises keeping sensitive objects on the server, with the cookie holding only an opaque reference.
Third, does any code rebuild objects from data a client can touch? The researcher advises dropping pickle across that boundary, in favour of a plain data format with a schema check.
Fourth, if a secret has been exposed, can you rotate it and end every session signed with it? The researcher lists this as the first fix.
A signature is a promise about who wrote something. It means little if the pen was left in the envelope.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: simonkoeck.com.
