Google DevSite Flaw Allowed Unauthenticated RCE via Forged Flask Sessions

A critical vulnerability discovered in Google's shared DevSite platform could have allowed unauthenticated attackers to forge Flask session cookies and achieve remote code execution (RCE) across multiple Google-owned developer websites. The flaw, reported by researcher Simon Koeck, affected prominent sites including developers.google.com, firebase.google.com, developer.android.com, source.android.com, and docs.partner.android.com. Google has since patched the vulnerability on October 7, 2026, after receiving the report in August and awarding the researcher $90,000 through its Vulnerability Reward Program.

The vulnerability chain began with a Flask session cookie issued by the DevSite OAuth endpoint. Flask's standard session mechanism signs cookies to prevent tampering, but it does not encrypt their contents. This means that while users cannot alter cookie data without the server's secret signing key, they can read the stored information. The issue escalated when it was discovered that the exposed OAuth client secret, found within the session data, was also being reused as the Flask session signing key. This reuse meant that any attacker who obtained a session cookie could recover the secret, generate a valid signature, and create a forged session that the server would trust, effectively bypassing a primary security control.

The ability to forge sessions alone could have allowed attackers to alter values within the Flask session. However, the true danger lay in how the DevSite OAuth callback handled an object stored in that session. The application reportedly Base64-decoded OAuth flow data and passed it directly to Python's pickle.loads() function. Python's documentation explicitly warns that the pickle module is insecure and should only be used with trusted data, as a malicious pickle payload can execute arbitrary code during the deserialization process.

An attacker, armed with the recovered signing key, could craft a valid session containing a malicious pickle object. When the OAuth callback processed this forged cookie, it would first verify the signature, then retrieve the attacker-controlled flow object, and finally unpickle it. This sequence would cause the server to execute code chosen by the attacker. While Simon Koeck did not execute system commands on Google infrastructure, their proof-of-concept demonstrated the exploit by using a harmless time-delay payload. Requests containing the forged payload were delayed by a number of seconds specified in the serialized object, confirming that the server processed the data and executed the selected Python function.

This vulnerability was particularly dangerous because it did not require a Google account to reach the OAuth authorization endpoint and obtain a session cookie. Furthermore, its presence on a shared platform rather than an isolated site amplified the potential impact across a wide range of Google's developer web properties. The combination of sensitive OAuth material in a client-side cookie, the reuse of the OAuth secret as the Flask signing secret, and the use of pickle for deserializing session-controlled data created a critical vulnerability.

Google remediated the issue by rotating the exposed OAuth client secrets, invalidating all sessions signed with them, separating Flask SECRET_KEY values from OAuth credentials, and moving OAuth flow objects to server-side storage. This incident underscores the importance of securely managing signing keys and avoiding the deserialization of untrusted data. Best practices suggest that browser cookies should only contain opaque session references, with sensitive state maintained server-side. Developers should also avoid using pickle in data paths influenced by external systems, opting instead for data-only formats like JSON with strict schema validation to prevent deserialization vulnerabilities.

This event serves as a stark reminder that signed sessions are only as secure as their signing keys, and applications must rigorously prevent attacker-controlled session data from being interpreted as executable code. The reuse of secrets and insecure deserialization patterns continue to be significant risks in web application security, even for major technology providers.