Verify OAuth Secrets After Researcher Exposes Google Dev Site RCE Flaw

A security researcher has demonstrated that unauthenticated remote code execution is possible on Google’s developer documentation websites. The flaw stems from a configuration error where Google’s OAuth client secret was embedded in plaintext within user session cookies. This secret also functioned as the cryptographic signing key for those sessions, allowing attackers to forge valid cookies and execute arbitrary code on the servers.

How was the vulnerability discovered?

The researcher was mapping the OAuth flow used across Google’s developer documentation sites. They observed that accessing the authorisation endpoint set a Flask session cookie before redirecting users to the sign-in page. The cookie was unusually large, containing approximately 1,200 bytes, which suggested it held more data than a standard CSRF token or return URL. Decoding the cookie revealed a pickle-serialised payload containing an OAuth2WebServerFlow object.

Why is this configuration critical?

The pickle payload contained Google’s OAuth client_id and client_secret in plaintext. The researcher tested whether this client secret also served as the Flask SECRET_KEY used to sign the session cookies. It did. By using the leaked secret, the researcher could generate valid signatures for any session payload. This meant session integrity was completely compromised, allowing the creation of forged cookies that the server would accept as authentic.

How does the remote code execution work?

The application’s callback endpoint reads the flow object from the session and unpickles it using pickle.loads. Because the signing key was public, an attacker could craft a malicious pickle payload containing arbitrary Python commands. When the server processed the forged cookie, it would execute the embedded code. The researcher proved this capability by using a time.sleep command to delay server responses, confirming unauthenticated remote code execution without running harmful commands on production systems.

What is the current status?

The researcher reported the finding after demonstrating the technical proof of concept. The source material does not confirm whether Google has released a patch or update to address the vulnerability. No CVE identifier or official statement from Google is included in the provided text. The researcher emphasised that the client secret was still live at the time of writing, indicating the flaw was active when the analysis was conducted.

What to do and how to stay safe: Google

• Monitor official security advisories from Google for updates regarding developer site vulnerabilities.
• Review your own applications to ensure OAuth secrets are never stored in client-side session cookies.
• Avoid using pickle for deserialising untrusted data, as it can lead to remote code execution.
• Verify that session signing keys are kept separate from application credentials like client secrets.

Step-by-step guide: Emergency Patching: The High Cost of Fixing Critical Flaws Fast

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

Frequently asked questions

Is this vulnerability being exploited in the wild?

The source material only describes a proof of concept demonstrated by the researcher; it does not state whether active exploitation is occurring.

Which Google services are affected?

The vulnerability affects Google’s developer documentation sites that share the specific OAuth flow described in the report.

Has Google issued a fix?

The provided source material does not mention a confirmed fix, patch, or update from Google.