FHN 
A critical security vulnerability in Google’s shared DevSite platform could have allowed attackers to execute remote code on multiple Google developer websites without authentication. The flaw was discovered by security researcher Simon Koeck, who identified a dangerous combination of exposed OAuth credentials, weak session security, and unsafe Python deserialization.
The vulnerability affected several Google-owned websites, including Google Developers, Firebase, Android Developers, Source Android, and Partner Android documentation. Because these websites relied on a shared platform, a single underlying security issue could potentially affect multiple services.
According to the researcher’s report, the vulnerability was reported to Google in August 2026. Google addressed the issue on October 7, 2026, and awarded Koeck $90,000 through its Vulnerability Reward Program.
The discovery highlights how mistakes in session management and data processing can create serious security risks, even in widely used developer platforms.
How the Google DevSite Flaw Exposed Sensitive Credentials
The vulnerability originated in the OAuth authentication flow used by Google DevSite. During the authentication process, the application generated a Flask session cookie containing information required to manage the OAuth flow.
Flask is a Python web framework that uses signed session cookies to protect session data against unauthorized modification. However, signing does not encrypt the contents of a cookie. Anyone who obtains it may be able to read the stored information, even though changing the contents should invalidate the signature.
During his investigation, Koeck discovered that the session cookie contained more information than expected. After decoding the compressed data, he identified a serialized OAuth flow object containing a Google OAuth client ID and client secret.
The most serious finding was that the exposed OAuth client secret was also being used as the Flask session signing key.
Normally, an attacker cannot modify a signed session cookie successfully without knowing the secret key used to sign it. However, when the signing key is exposed within the session data itself, that protection can no longer be trusted.
An attacker who obtained the relevant cookie could recover the secret, generate a valid signature, and construct a forged session that the application would accept.
This meant the problem was not limited to information disclosure. It potentially allowed attackers to control data that the application considered trustworthy, creating an opportunity to exploit other weaknesses in the authentication process.
Unsafe Python Deserialization Created a Remote Code Execution Risk
The vulnerability became significantly more dangerous because of how the DevSite application processed the OAuth flow object stored in the session.
According to the researcher’s findings, the application decoded the stored data and passed it to Python’s pickle.loads() function. The pickle module is designed to serialize and deserialize Python objects, but it is unsafe when used with untrusted or attacker-controlled data.
Unlike data-only formats, a malicious pickle object can execute Python code during deserialization. This means that an application can introduce a code execution vulnerability simply by loading a crafted object without verifying that the data is trustworthy.
In this case, the exposed Flask signing key provided a way to create a forged session that could pass the application’s signature verification. The attacker could then supply a crafted serialized object as part of the session data.
When the OAuth callback processed the forged session, the application could deserialize the attacker-controlled object and execute code on the server.
The combination of these weaknesses created a potential remote code execution chain:
- The application stored sensitive OAuth information in a client-side session cookie.
- The OAuth client secret was reused as the Flask session signing key.
- An attacker could potentially recover the key and forge a valid session.
- The application deserialized session-controlled data using Python’s pickle module.
- Processing a malicious object could trigger attacker-controlled code execution.
Koeck demonstrated the issue using a harmless time-delay payload rather than executing system commands on Google’s infrastructure. Requests containing the crafted payload reportedly experienced delays matching the time specified in the serialized object.
This proof of concept demonstrated that the server was processing the crafted object in a way that could trigger the intended behavior.
The issue was particularly concerning because the OAuth endpoint could reportedly be reached without a Google account. Combined with the shared DevSite architecture, this increased the potential exposure across several Google developer properties.
However, the findings demonstrate a potential exploitation path; they do not establish that attackers exploited the vulnerability in real-world attacks or that every affected website was successfully compromised.
Google Remediated the Vulnerability and Strengthened Session Security
Google addressed the vulnerability by making several changes to the authentication and session-management design.
According to the researcher’s report, the remediation included rotating the exposed OAuth client secrets, invalidating sessions signed with the affected secrets, separating Flask signing keys from OAuth credentials, and moving OAuth flow objects to server-side storage.
These changes addressed the main weaknesses that made the attack possible. Rotating exposed credentials reduced the risk of continued abuse, while separating signing keys from OAuth secrets prevented the same credential from serving multiple security purposes.
Moving OAuth flow objects to server-side storage also reduced the amount of sensitive information that needed to be placed in browser cookies.
The incident offers several important lessons for developers and security teams.
Keep session signing keys separate from application credentials. Secrets used to sign session cookies should be unique, securely stored, and never included in data that clients can access. Reusing one secret for multiple purposes increases the impact of a single exposure.
Avoid deserializing untrusted data with pickle. Python developers should never use pickle.loads() on data that can be influenced by browsers, external integrations, or other untrusted sources. JSON or another data-only format is generally a safer choice when combined with strict schema validation and appropriate input handling.
Keep sensitive session state on the server. Browser cookies should ideally contain only an opaque session identifier or similarly limited information. Sensitive OAuth tokens, credentials, and complex authentication objects should remain in protected server-side storage.
Review shared platforms for systemic weaknesses. A vulnerability in a common authentication component can affect multiple websites at once. Organizations should regularly assess shared libraries, authentication flows, session-management mechanisms, and credential-handling practices.
Google’s response demonstrates why security vulnerabilities involving authentication and remote code execution require careful investigation and prompt remediation. Although signed cookies can provide useful integrity protection, their security depends on keeping signing keys secret and ensuring that applications handle session data safely.
The Google DevSite incident serves as a reminder that secure authentication requires more than signing a cookie. Sensitive credentials must be protected, session data must be handled carefully, and applications must never treat potentially attacker-controlled serialized objects as safe to execute.
About the Author
