Researcher Discovers Remote Code Execution Flaw in Google Developer Sites
A security researcher found that Google’s developer documentation sites exposed an OAuth secret that allowed unauthenticated remote code execution via pickle deserialization.
Key points
- The vulnerability existed in the OAuth flow shared by Google’s developer documentation websites.
- A pickle-serialized session cookie contained the application’s OAuth client secret in plaintext.
- The leaked secret served as the Flask signing key, enabling attackers to forge valid sessions.
A security researcher identified a remote code execution vulnerability within Google’s developer documentation infrastructure, according to a report published on Hacker News. The flaw allowed unauthenticated attackers to execute arbitrary code on the server by manipulating session cookies during the OAuth authorization process.
The researcher mapped the OAuth flow used by Google’s developer docs sites, noting that the /oauth2authorize endpoint sets a Flask session cookie before redirecting users to the sign-in page. This cookie was approximately 1,200 bytes long, which was significantly larger than expected for standard CSRF tokens and return URLs. Decoding the cookie revealed a pickle-serialized payload containing an OAuth2WebServerFlow object.
Technical Details of the Vulnerability
The pickle payload included Google’s OAuth client_id and client_secret in plaintext, according to the researcher’s write-up. The client secret was still live at the time of the discovery. The researcher discovered that this same client secret functioned as the Flask SECRET_KEY used to sign the session cookie. By using the leaked secret, the attacker could generate valid signatures for any custom session data.
The callback mechanism on the server reads the flow object from the session and unpickles it using pickle.loads. Because the signing key was publicly accessible within the cookie itself, session integrity was compromised. The researcher demonstrated this by creating a forged session with a custom CSRF token and a malicious pickle payload.
To prove the remote code execution capability without impacting production systems, the researcher used a payload that executed the time.sleep function. The server accepted the forged session and executed the command, confirming that the application would run any code provided in the unpickled object. The state parameter was also controlled by the attacker, requiring no additional server-side alignment.
Impact and Exposure
The vulnerability affected Google’s developer documentation sites, which share a common OAuth implementation. Because no account was needed to trigger the flow, any user could access the /oauth2authorize endpoint and receive the vulnerable cookie. The exposure of the client secret in plaintext was a significant finding, but the ability to forge session signatures was the critical component enabling remote code execution.
The researcher noted that the pickle.loads function is only safe if the signing key remains secret. Once the key is public, an attacker can inject arbitrary Python objects into the session. The combination of a leaked secret and an unsafe deserialization sink resulted in unauthenticated remote code execution on the server.
What should you do?
Security teams should review their OAuth implementations for similar patterns where secrets are stored in client-side sessions. Organizations using Flask or other frameworks with pickle-based session storage should ensure that signing keys are never exposed to users. Monitoring for unusual session sizes or unexpected deserialization errors can help detect similar misconfigurations.
What to do and how to stay safe: Google
- Audit OAuth flows to ensure client secrets are never transmitted in client-side cookies or session data.
- Avoid using pickle or other unsafe deserialization libraries for session storage in web applications.
- Verify that session signing keys are stored securely on the server and are not accessible to end users.
- Monitor server logs for unexpected deserialization attempts or large session cookies that may indicate exploitation.
Step-by-step guide: Risk Based Vulnerability Management: Prioritize Fixes by Actual Threat
General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
What was the root cause of the remote code execution vulnerability?
The root cause was the use of a pickle-serialized session cookie that contained the OAuth client secret, which also served as the Flask signing key.
Did the researcher exploit the vulnerability on Google’s production servers?
No, the researcher proved the vulnerability by executing a time.sleep command to demonstrate remote code execution without causing harm.
Is there a patch available for this vulnerability?
The source material does not confirm whether a patch or fix has been released by Google for this specific issue.
