Google has addressed a critical vulnerability in its DevSite platform that could have allowed unauthenticated attackers to execute arbitrary code across multiple developer sites. Discovered by researcher Simon Koeck, the flaw centered on improperly handled Flask session cookies used during OAuth flows. It affected sites including developers.google.com, firebase.google.com, developer.android.com, source.android.com, and docs.partner.android.com. The patch was deployed on October 7, 2026, following a report submitted in August, and Koeck was awarded $90,000 under Google’s Vulnerability Reward Program.
How the chain of flaws escalated
At the root of the vulnerability was Google’s use of Flask session cookies that stored various data without encryption—only signed using Flask’s SECRET_KEY. These cookies packed more than a CSRF token and a return URL; the payload also contained a serialized OAuth flow object, which included both the OAuth client ID and, crucially, the client secret. Because OAuth secrets were used as the same key for signing session cookies, anyone with a valid session could extract this secret from the cookie and then craft new forged sessions that passed signature checks.
The real danger emerged in how Flask session data was used during the OAuth callback. The application decoded the serialized flow data and handed it off to Python’s pickle.loads() function— a combination that can enable remote code execution if unchecked. With the client’s signing key exposed, an attacker could place a maliciously crafted pickle payload into a forged cookie. When the callback processed it, the unpickling operation could execute arbitrary code on the server.
Potential reach and scope of impact
No Google account was required to trigger the vulnerability, since anyone could access the OAuth endpoint and receive a session cookie. Because the flaw affected a shared platform rather than isolated services, its potential reach was far bigger, spanning several Google-owned developer properties.
In a proof-of-concept, Koeck demonstrated the risk by embedding a time-delay payload in a malicious pickle object delivered via a forged session cookie. The server processed it exactly as instructed, confirming that the callback had both validated the signature and carried out the unpickling, effectively running attacker-controlled code, though the test was harmless.
How Google fixed it
To remediate the issue, Google rotated all affected OAuth client secrets and invalidated any existing sessions that had been signed using them. It also separated OAuth credentials from Flask’s SECRET_KEY, so that the signing key would no longer be reused for sensitive credentials. The flow data used during OAuth was moved from the client-side cookie into server-side storage. Best practices reinforced by the fix include treating session cookies as opaque references rather than data carriers and replacing unsafe serialization formats like pickle—favoring JSON or similarly constrained formats with strict validation.
This incident serves as a vivid reminder: signing session cookies is not enough if the secret key can be retrieved via the session. Equally: deserializing data from client-controllable sources—especially using modules with code-execution potential—can lead to catastrophic risks. Teams leveraging Flask or similar frameworks must make design choices that avoid client-side exposure of secrets and unguarded object deserialization.
Google’s DevSite vulnerability illustrates how multiple relatively standard weaknesses can align into a serious remote code execution threat. The key lessons—never reuse signing keys for other secrets, store sensitive state serverside, avoid pickle where users or cookies can manipulate inputs—should resonate beyond just Google’s infrastructure. Organizations using Flask or any session-based architecture should audit for similar patterns. It’s what the industry must watch closely as more high-impact bugs emerge in 2026.
