A security researcher uncovered an unauthenticated remote code execution vulnerability in Google's developer documentation infrastructure that required no account or user interaction to exploit, according to a detailed account published by The New Stack. Google assigned the flaw its highest severity rating and awarded the researcher $90,000, but took two months to deploy a fix after accepting the report. The vulnerability affected seven domains including developers.google.com and allowed anyone to forge valid session cookies and execute Python code on the server.
Simon Köck, a software engineer at Otark GmbH, discovered the weakness in Google's DevSite infrastructure, the shared platform powering developers.google.com and several related documentation sites. Köck confirmed the vulnerability worked across all seven affected domains, which depended on two different signing keys, and successfully ran his code-execution proof on three sites: developers.google.com, docs.partner.android.com, and web.dev. Google rated the vulnerability S0, the top tier of its severity scale, and granted Köck a $90,000 bounty that included a $75,000 base payment for an S0 remote code execution in what Google categorizes as a normal application tier, multiplied by 1.2 for exceptional report quality. Köck verified the unauthenticated remote code execution using a Python sleep payload and measuring response delays that aligned with his payload, deliberately avoiding running commands or accessing files, credentials, or internal services.
The root cause involved three separate mistakes that aligned to create the exploit chain. DevSite stored a serialized OAuth2WebServerFlow object from Google's oauth2client library, which Google has deprecated in favor of google-auth, inside a Flask session cookie, exposing the OAuth client secret in the process. Google had reused that same OAuth client secret as DevSite's Flask session-signing key, which Köck confirmed by reproducing the cookie's signature offline, giving him the ability to forge sessions the server would accept. The OAuth callback used Python's pickle to deserialize session data, so Köck swapped the flow object for a malicious pickle payload, signed the forged cookie, and let the callback execute it. "I'd call it an exceptionally serious RCE because anyone could reach it without an account or victim interaction," Köck said, though he noted he doesn't know whether the three hosts he tested shared the same backend machines.
The timeline and potential impact raise significant concerns. Köck reported the vulnerability on August 6, Google accepted it the following day, and the company approved the bounty on August 27 but didn't deploy a fix until October 7. Google hasn't explained the two-month remediation window or disclosed whether it implemented interim safeguards, and questions remain about the fix itself, including whether both signing keys were rotated or existing sessions were invalidated. Singapore-based researcher Arvin Shivram has since pointed out that internal App Engine apps often have access to Stubby, Google's internal service-to-service communication system, which Köck acknowledged "could be a major part of the impact," though he said he didn't verify what this particular DevSite process could reach. One concern is whether an attacker could have modified Google's developer documentation, replacing installation commands or download links with malicious ones that could enable a supply-chain attack, but Köck didn't test for write access to the content systems, and Google hasn't disclosed DevSite's process permissions or backend access. Köck was never given a forensic conclusion and doesn't know whether Google found evidence of exploitation before the patch, and the company hasn't said either. The extended remediation period for a severity-zero flaw with no authentication barrier highlights the operational friction that can exist even within security-conscious organizations. Supply-chain attacks through compromised documentation represent an especially potent threat vector because developers inherently trust official installation instructions and tend to execute them with elevated privileges.