Google paid a $90,000 bounty to security researcher Simon Köck after he discovered an undocumented remote code execution vulnerability in DevSite, the shared platform that supports developers.google.com and other documentation sites. Köck reported the issue on August 6, Google accepted the report the next day, and approved the bounty on August 27, but the fix reached the servers on October 7.
Google classified the vulnerability as S0, the highest level on its severity scale, and awarded Köck a base amount of $75,000 for an RCE vulnerability in the regular application layer, with a 20% increase for the exceptional quality of the report.
Three errors formed the exploitation chain
DevSite stored a serialized OAuth2WebServerFlow object from the deprecated oauth2client library inside a Flask session cookie. This exposed an OAuth client secret, but the issue became more serious because the same secret was also used as the key to sign Flask sessions.
Köck was able to reproduce the cookie signing locally and create forged sessions accepted by the server. Because the OAuth flow used pickle to deserialize session data, he was able to replace the object with a signed malicious pickle payload and then demonstrate remote Python code execution.
The researcher confirmed execution using a payload that delayed the response through a sleep command and deliberately stopped before running actual commands or accessing files, credentials, or internal services. According to his account, forged sessions were accepted on all seven affected domains, while the proof-of-concept test was performed on three domains: developers.google.com, docs.partner.android.com, and web.dev.
The full scope of the impact remained unresolved
Köck did not establish whether the server could modify Google documentation content or replace installation commands and download links, a scenario that could have opened the door to a software supply-chain attack. He also did not test whether the forged sessions enabled user impersonation or access to their data.
Researcher Arvin Shivram, known as @brutecat, noted that internal App Engine applications can typically access Stubby, Google’s internal system for service-to-service communication. Köck said that access, if available to this process, could significantly expand the impact, but he did not verify DevSite’s privileges or its scope of access to backend services.
Why does this matter?
The case shows that the risk did not result from a single error, but from the combination of three practices: exposing a sensitive secret inside a cookie, reusing it as a signing key, and using unsafe deserialization for untrusted data. Fixing any one link in this chain would have been enough to break the exploitation path, making the separation of secrets and rejection of pickle in session data essential controls rather than optional improvements.
At the same time, the roughly two-month remediation period raises operational questions that Google did not answer. The company did not clarify whether it had applied temporary mitigations, rotated the two different signing keys that Köck said the seven domains used, or invalidated existing sessions. It also did not disclose a forensic determination regarding whether the vulnerability had been exploited before the patch was deployed, and had not responded to The New Stack’s request for comment when the article was updated.