Google DevSite Vulnerability Could Enable Remote Code Execution Through Forged Flask Sessions

Introduction

A critical vulnerability in Google’s shared DevSite platform could have allowed unauthenticated attackers to forge Flask session cookies and execute code on Google-owned developer websites. Security researcher Simon Koeck discovered the issue, which reportedly affected several properties, including Google Developers, Firebase, Android Developers and Android Open Source Project documentation.

According to the published research, Google fixed the vulnerability on 7 October 2026 after receiving the report in August. The researcher reportedly received a $90,000 reward through Google’s Vulnerability Reward Program. The incident highlights the risks of exposed application secrets, insecure session management and unsafe Python deserialization.

How the Google DevSite Vulnerability Worked

The vulnerability involved the OAuth authentication flow used by Google’s DevSite platform. The application issued Flask session cookies containing information about the OAuth process.

Flask signs session cookies to protect their integrity, but its default session mechanism does not encrypt their contents. The researcher reportedly discovered that the decoded session data contained an OAuth client secret that was also used as Flask’s signing key.

This created a serious security weakness. If an attacker obtained the cookie and recovered the signing secret, they could potentially generate forged session cookies that the application would accept as legitimate.

The issue affected multiple developer websites sharing the same platform, increasing the potential scope of the vulnerability.

How Forged Sessions Could Lead to Remote Code Execution

The most serious aspect of the flaw involved Python’s pickle module. According to the researcher’s technical disclosure, the OAuth callback decoded session data and passed a stored object to pickle.loads().

Python’s pickle mechanism can execute code when deserializing maliciously crafted data. It is therefore unsafe to process untrusted or attacker-controlled pickle payloads.

Because the exposed secret could reportedly be used to forge a valid session, an attacker could construct session data containing a malicious serialized object. When the OAuth callback processed that data, deserialization could trigger attacker-controlled code execution.

The researcher reportedly demonstrated the behaviour using a harmless time-delay proof of concept rather than executing system commands on Google’s infrastructure.

This illustrates how multiple weaknesses can combine into a critical vulnerability: exposed secrets undermine session integrity, while unsafe deserialization turns manipulated session data into a potential code-execution vector.

Google’s Response and Remediation

According to the published disclosure, Google addressed the issue through several security improvements:

• Rotating the exposed OAuth client secrets.
• Invalidating sessions signed with the compromised secrets.
• Separating Flask signing keys from OAuth credentials.
• Moving OAuth flow objects to server-side storage.

These measures reduce the likelihood that sensitive authentication information can be recovered from browser cookies and reused to forge trusted sessions.

How Developers Can Prevent Similar Vulnerabilities

Developers should follow several security practices to protect web applications:

1. Protect signing keys: Keep Flask SECRET_KEY values confidential and separate from API keys, OAuth secrets and other credentials.
2. Avoid unsafe deserialization: Never use pickle.loads() on data that may be influenced by users or external systems.
3. Use server-side session storage: Store sensitive authentication state on the server and keep browser cookies limited to protected session identifiers.
4. Rotate compromised credentials: Revoke exposed secrets and invalidate potentially affected sessions promptly.
5. Validate OAuth flows: Apply appropriate state validation, secure cookie settings and robust authentication checks.

Conclusion

The Google DevSite vulnerability demonstrates how insecure secret management and unsafe deserialization can combine to create a serious remote code execution risk. Although the issue has reportedly been fixed, it provides an important lesson for developers building authentication systems.

Protecting session-signing keys, avoiding unsafe deserialization and storing sensitive state server-side are essential steps towards stronger application security.

Security takeaway: A signed session is only trustworthy when its signing key remains secret and its contents cannot trigger unsafe operations.