Google DevSite Flaw Let Attackers Execute Remote Code Through Forged Flask Sessions

A critical vulnerability in Google’s shared DevSite platform could have allowed an unauthenticated attacker to forge Flask session cookies and trigger remote code execution across several Google-owned developer websites, according to researcher Simon Koeck.

The issue affected the OAuth flow used by Google developer documentation sites, including developers.google.com, firebase.google.com, developer.android.com, source.android.com, and docs.partner.android.com.

Google reportedly fixed the flaw on October 7, 2026, after receiving the report in August and awarding the researcher $90,000 through its Vulnerability Reward Program.

The bug chain started with a Flask session cookie issued by the DevSite OAuth endpoint. Flask’s standard session mechanism signs cookies to protect them from changes, but it does not encrypt their contents.

That means users can read the stored data, even though they can’t alter it without the server’s secret signing key. Flask documentation states that the SECRET_KEY is used to sign session cookies and other security-sensitive data securely.

In this case, the cookie reportedly held more than a CSRF token and return URL. After decoding the compressed payload, the researcher found a serialized OAuth flow object that included a Google OAuth client ID and client secret.

Critical Google DevSite Flaw

The discovery became more serious when Simon Koeck confirmed that the exposed OAuth client secret also served as the Flask session signing key, exposing the key within session data.

Anyone who obtained a cookie could recover the secret, generate a new valid signature, and create a forged session that the server would trust. This removed the main security control protecting the application from client-side session tampering.

The forged-session issue alone could have enabled attackers to alter values held in the Flask session. The code-execution risk came from how the DevSite OAuth callback handled an object stored in that session.

The application reportedly Base64-decoded the OAuth flow data and passed it to Python’s pickle.loads() function. Python’s documentation warns that the pickle module is not secure and that developers must unpickle only data they fully trust, because a malicious pickle payload can execute code while it is being restored.

An attacker with the signing key could therefore create a valid session containing a crafted pickle object. When the OAuth callback processed the forged cookie, it would verify the signature, retrieve the attacker-controlled flow object, and unpickle it. That could cause the server to run code chosen by the attacker.

Simon Koeck did not run system commands on Google infrastructure. Instead, the proof of concept used a harmless time-delay payload.

Requests containing the forged payload were reportedly delayed by the exact number of seconds specified in the serialized object, showing the server processed the data and ran the selected Python function.

This was an especially dangerous chain because no Google account was required to reach the OAuth authorization endpoint and receive the session cookie. The issue also affected a shared platform rather than one isolated site, expanding its possible impact across Google’s developer web properties.

Google’s prior fixes for critical cloud code-execution issues show why this category receives high priority in vulnerability-reward programs. In a separate 2026 case, Google addressed a CVSS 10.0 Application Integration flaw that enabled remote code execution in production environments.

The case combined several dangerous design choices. First, a client-side cookie contained sensitive OAuth material. Second, the exposed OAuth secret was reused as the Flask signing secret. Third, the application deserialized session-controlled data with pickle, which is unsafe once an attacker can bypass integrity checks.

Simon Koeck said Google remediated the problem by rotating the exposed OAuth client secrets, invalidating sessions signed with them, separating Flask SECRET_KEY values from OAuth credentials, and moving OAuth flow objects to server-side storage.

The safer design is for a browser cookie to carry only an opaque session reference. At the same time, sensitive state remains on the server.

Developers should also remove pickle from data paths that a browser, user, partner integration, or external system can influence. JSON or another data-only format, combined with strict schema validation, prevents deserialization from becoming code execution.

For related coverage, readers can review Cyber Security News reporting on Google Cloud production RCE vulnerabilities and Google Gemini CLI command-execution flaws.

Google’s DevSite incident is another reminder that a signed session is only trustworthy when the signing key stays secret, and the application never turns attacker-controlled session data into executable objects.

Stops threats before impact with 21 min faster MTTR. Integrate ANYRUN’s Sandbox in your SOC

The post Google DevSite Flaw Let Attackers Execute Remote Code Through Forged Flask Sessions appeared first on Cyber Security News.