Google Dev Sites Expose RCE via Pickle Deserialization in Flask Session

Security researcher Simon Koeck discovered a remote code execution vulnerability in Google’s developer documentation sites. The flaw allows attackers to run arbitrary code on the servers by forging session cookies, according to a write-up published on Koeck’s personal website. The issue stems from how the sites handle OAuth flows and session management.

The vulnerability exists because the sites use Flask session cookies that contain pickle-serialised objects. Koeck noted that the cookies were significantly larger than expected for standard CSRF tokens. Upon decoding, the payload revealed an OAuth2WebServerFlow object. Crucially, this object contained the Google OAuth client_id and client_secret in plaintext. The client secret was also used as the Flask SECRET_KEY for signing the cookie.

Technical Details of the Flaw

Koeck verified that the client secret could be used to generate valid signatures for the session cookies. By reversing one character of the signature, the request was rejected, confirming the key's validity. With the signing key exposed in the cookie payload, an attacker could create a custom session. The server accepts this forged session because the signature validates against the leaked secret.

The application then unpickles the flow object from the session using pickle.loads. Because the signing key is public, session integrity is effectively broken. An attacker can insert any pickle payload into the session. When the server processes the callback, it executes the deserialised object, leading to remote code execution. Koeck demonstrated this by forcing the server to execute time.sleep commands.

Impact and Exposure

The flaw affects the shared OAuth flow used across Google’s developer documentation sites. No user account is required to trigger the initial cookie issuance. The /oauth2authorize endpoint sets the vulnerable Flask session cookie before redirecting to Google’s sign-in page. This means any visitor can receive a cookie containing the serialised object and the leaked secret. The exposure of the secret itself is a significant finding, but the ability to forge signatures elevates the risk to full remote code execution.

What happens next

Koeck did not execute harmful commands on Google’s production environment, choosing instead to prove the concept using time delays. The write-up details the technical steps required to exploit the vulnerability. Google has not yet published a statement or a patch for this specific issue, according to the report. Security teams monitoring for pickle deserialization flaws should note this as a high-risk pattern.

What to do and how to stay safe: Google

• Audit applications for Flask session cookies that contain serialised objects or large payloads.
• Ensure that signing keys are never stored within the data they sign or in client-side cookies.
• Review OAuth implementations to prevent leakage of client secrets in URLs or cookies.
• Monitor for unexpected server delays or resource spikes that may indicate deserialization attacks.

Step-by-step guide: Patch Management Policy: How to Automate Fixes Without Breaking Systems

General security guidance from the Payload Report newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

What is the root cause of this vulnerability?

The root cause is the use of a leaked OAuth client secret as the Flask session signing key, combined with unsafe pickle deserialization.

Can an attacker execute commands without authentication?

Yes, because the signing key is public, an attacker can forge valid session cookies to trigger remote code execution.

Which Google services are affected?

The vulnerability affects the shared OAuth flow used by Google’s developer documentation sites.