Google Took Two Months to Fix Unauthenticated RCE in DevSite Developer Documentation Platform

A Reused Secret Turned Into Remote Code Execution

Google has patched an unauthenticated remote code execution (RCE) vulnerability in DevSite, the shared platform behind developers.google.com and several sibling documentation sites. The flaw, which Google rated S0, the top of its severity scale, was found by Simon Köck, a software engineer at Otark GmbH.

The root cause was a reused OAuth client secret. DevSite stored a serialized OAuth2WebServerFlow object from Google's oauth2client library, which the company has deprecated in favor of google-auth, inside a Flask session cookie, exposing the secret. Google had also reused that same secret as DevSite's session-signing key, which Köck confirmed by reproducing the cookie's signature offline.

Forged Sessions Accepted on Seven Domains

Köck confirmed that forged sessions were accepted on all seven affected domains, which relied on two different signing keys. He demonstrated code execution on three of them: developers.google.com, docs.partner.android.com and web.dev. He verified unauthenticated RCE with a Python sleep payload, measuring response delays that matched, and deliberately stopped short of running commands or touching files, credentials or internal services.

"I'd call it an exceptionally serious RCE because anyone could reach it without an account or victim interaction," Köck tells The New Stack.

Google paid a $90,000 bounty: a $75,000 base payout for an S0 RCE in what the company classifies as a normal application tier, multiplied by 1.2 for exceptional report quality.

Pickle Deserialization Completed the Chain

The OAuth callback used Python's pickle to deserialize session data. Köck swapped the flow object for a malicious pickle payload, signed the forged cookie and let the callback execute it. The chain required three mistakes to line up: a secret exposed in the cookie, that same secret doing double duty as a signing key, and unsafe deserialization of session data. Fixing any one of them would have broken it.

Two Months to Patch, Unanswered Questions Remain

Köck reported the vulnerability on August 6 and Google accepted it the following day. The bounty was approved on August 27, but the fix was not deployed until October 7. Google has not explained the two-month remediation window, whether it implemented interim mitigations, or whether either of the two exposed OAuth client secrets was rotated and existing sessions invalidated. Köck says he was never given a forensic conclusion and does not know whether Google found evidence of exploitation before the patch. Google had not responded to a request for comment as of this update.

Arvin Shivram, a Singapore-based researcher who goes by @brutecat and has reported more than 130 Google vulnerabilities by his own count, pointed out that internal App Engine apps often have access to Stubby, Google's internal service-to-service communication system. Köck acknowledges that access "could be a major part of the impact," though he did not verify what this particular DevSite process could reach. He also did not test write access to documentation content, where altered installation commands or download links could have enabled a supply-chain attack. By his accounting, the demonstrated impact is code execution on three hosts and forged sessions accepted on seven, while the full blast radius, including any path into Google's internal services, remains unproven.

Sources: Thenewstack