Google has paid a researcher $90,000 for an unauthenticated remote code execution flaw in DevSite, the shared platform that serves its developer documentation sites. The bounty was agreed within three weeks, but the fix did not ship until two months after the report, and that gap deserves a close look from anyone who runs a bug bounty or disclosure programme.
What happened
On 12 October 2026, software engineer Simon Koeck of Otark GmbH published a write-up of a critical vulnerability he had reported to Google’s Vulnerability Reward Program (VRP). The flaw sat in DevSite, the platform behind developers.google.com and sibling sites. According to Koeck, the same weakness produced valid sessions on developer.android.com, firebase.google.com, docs.partner.android.com and source.android.com. He says seven domains, using two signing keys, were affected; six have been named, including web.dev, one of three hosts where he proved code execution.
Google classed the issue as S0, its highest severity rating, under the “Normal Google Applications” tier. A $75,000 base reward, lifted by a 1.2 quality multiplier, produced the $90,000 payout.
The timeline Koeck published is unusually precise. He submitted the report late on 6 August, Google triaged and accepted it the next day, and the reward was decided on 27 August. The fix, however, was not deployed until 7 October: roughly nine weeks between acceptance and remediation. The New Stack reported that Google had not explained the delay, had not said whether any interim mitigation was in place, and had not confirmed whether it found any sign of exploitation before the patch. Google had not responded to its request for comment at the time of publication.
The technical picture
The problem began with the OAuth sign-in flow that all DevSite properties share. Reaching the authorisation endpoint, with no Google account at all, returned a session cookie far larger than a token and return address should ever need. These cookies, generated by the Flask web framework, are signed but not encrypted, so anyone holding one can read what is inside.
Inside, Koeck found a serialised object from the deprecated oauth2client library, stored in Python’s pickle format. That object carried Google’s OAuth client identifier and client secret in plain text. The decisive finding was that this same client secret was also the key signing the session cookie. The value meant to guarantee the cookie’s integrity was being handed to every visitor inside the cookie itself.
Once a signing key is public, the guarantee it provides collapses. An attacker in possession of it can assemble session contents of their choosing and present them with a signature the server accepts as genuine. When the sign-in process later read the stored object back out of the session, it reconstructed it through pickle, a format well understood to be unsafe when fed attacker-controlled data, because reconstructing an object can trigger code execution. A forged, server-trusted session therefore became a route to running code on Google’s infrastructure without any authentication.
Koeck was careful not to run commands against Google’s production systems. He demonstrated the issue with a harmless timing technique, measuring how the server’s response time shifted with a delay value he supplied. The delays tracked his chosen figures, confirming his data was executed rather than merely parsed.
Why it matters for UK organisations
The engineering mistakes here are common in UK estates, and I see versions of them on test engagements regularly. Reusing one secret for two purposes, trusting a signed-but-readable token, and deserialising attacker-reachable data are not exotic. They turn up in internal portals, self-service sites and the bespoke integrations that accumulate around single sign-on.
The documentation platforms involved also matter in their own right. Developer documentation is a supply-chain surface: if an attacker could alter the code samples that engineers copy and paste, the blast radius extends well beyond one company. Koeck did not test for write access, so whether tampering was possible is unknown. British development teams lean heavily on exactly these sites.
There is also a programme-management lesson with a UK flavour. The NCSC’s longstanding Vulnerability Disclosure Toolkit pushes organisations towards structured, timely handling of researcher reports. A bounty paid quickly but a fix delayed for weeks is precisely the pattern good governance is meant to prevent. Paying the researcher is not the end of the obligation.
Expert view
In my experience, the money is the easy part of a bug bounty programme; the hard part is the remediation pipeline behind it. A quick, generous payout followed by a two-month wait for a patch tells you the triage function is working but the fix-and-deploy function is not. That gap is where organisations get hurt, because the clock on real-world exploitation starts at discovery, not when someone finally merges a change.
What stands out technically is how ordinary each link in the chain is. None of it required a novel class of attack: just a secret doing two jobs, a token that could be read, and a dangerous deserialisation sink reachable once trust was broken. Koeck observes that any one of four straightforward fixes would have broken the chain. When several mundane weaknesses line up, you get unauthenticated code execution out of what looks like routine web plumbing.
Koeck’s write-up sets out what needed to change: rotate the exposed secrets and invalidate sessions signed with them, separate the signing key from the OAuth credential, and move the flow object to server-side storage. Some coverage has presented these as Google’s actual response, but his timeline records only the date of the fix. The New Stack noted Google had not confirmed whether both secrets were rotated or sessions invalidated, so treat that detail as unconfirmed.
What to do now
This is a good prompt to check your own authentication and session handling for the same shortcuts. Practical, prioritised steps:
- Give signing keys one job. A session-signing secret should never double as an API or OAuth credential, and it should come from a server-side secrets store with high entropy.
- Treat signed tokens as readable. Signing proves integrity, not confidentiality. Never place a secret or sensitive state inside a client-side cookie; keep it server-side and hand the client only an opaque reference.
- Remove unsafe deserialisation from attacker-reachable paths. Replace formats such as pickle with a data-only format and strict schema validation wherever input crosses a client boundary.
- Measure time-to-fix, not just time-to-reward. If you run a VDP or bounty, track remediation against severity-based service levels and escalate when a critical fix stalls. This maps directly to the Cyber Essentials expectation that high-risk vulnerabilities are addressed promptly.
- Rotate and invalidate after exposure. Rotating an exposed secret is only half the job. Invalidate every session or token derived from it, and confirm the invalidation took effect.
Bottom line
A $90,000 payout for a clean unauthenticated RCE is the bug bounty system working as intended, and Google’s VRP paid fairly and fast. The uncomfortable part is the two-month wait for the fix, and the fact that the underlying mistakes, secret reuse, readable tokens and unsafe deserialisation, are the sort of thing many UK organisations are quietly carrying in their own code. Reward is not remediation, and the report is not closed until the patch is live and the exposed secrets are dead.
Sources
- Simon Koeck: How I Found a $90,000 Remote Code Execution Vulnerability in Google
- The New Stack: Google paid $90,000 for this bug, then waited two months to fix it
- Cyber Security News: Google DevSite Flaw Let Attackers Execute Remote Code Through Forged Flask Sessions
- GBHackers: Critical Google DevSite Flaw Allowed Attackers to Execute Remote Code Without Authentication
