Researcher Finds RCE Flaw in Google DevSite via Flask Session Forgery
Simon Koeck discovered that unauthenticated attackers could forge session cookies to execute remote code on multiple Google developer sites.
Key points
- Google fixed the DevSite vulnerability on October 7, 2026, after receiving the report in August.
- The flaw allowed remote code execution by exploiting a shared secret between OAuth and Flask signing.
- A payout of $90,000 was awarded to researcher Simon Koeck through the Vulnerability Reward Program.
Security researcher Simon Koeck identified a vulnerability in Google’s shared DevSite platform that could have allowed unauthenticated attackers to execute remote code, according to Cyber Security News. The flaw involved forging Flask session cookies to bypass authentication controls on several developer documentation sites. Google addressed the issue on October 7, 2026, following the August submission of the report.
The vulnerability chain originated with the Flask session cookie issued by the DevSite OAuth endpoint. Flask signs these cookies to prevent tampering but does not encrypt their contents, allowing users to read stored data without the server’s secret key. Koeck found that the compressed payload within the cookie contained a serialized OAuth flow object, which included both a Google OAuth client ID and a client secret.
How the Exploit Worked
The severity of the issue escalated when Koeck confirmed that the exposed OAuth client secret also functioned as the Flask session signing key. This configuration error meant the cryptographic key was effectively stored within the session data itself. Any individual who obtained a cookie could decode it, recover the secret, and then generate a new valid signature for a forged session that the server would accept as legitimate.
This capability removed the primary security control designed to protect the application from client-side session manipulation. The researcher demonstrated that an attacker could alter values held in the Flask session using this forged signature. The path to remote code execution emerged from how the DevSite OAuth callback processed an object stored in that session, creating a dangerous combination of session forgery and unsafe data handling.
The application reportedly Base64-decoded the OAuth flow data and passed it directly to Python’s pickle.loads() function. Python documentation explicitly warns that the pickle module is not secure and should only be used with data that is fully trusted, because malicious payloads can execute arbitrary code during the unpickling process. An attacker with the signing key could therefore craft a session containing a malicious pickle object.
Affected Systems and Resolution
The issue impacted the OAuth flow used across multiple Google-owned developer documentation platforms. Affected sites included developers.google.com, firebase.google.com, developer.android.com, source.android.com, and docs.partner.android.com, according to Cyber Security News. Google reportedly fixed the flaw on October 7, 2026, after receiving the report in August and awarding the researcher $90,000 through its Vulnerability Reward Program.
The discovery highlights the risks of reusing secrets across different security contexts within web applications. By using the same key for OAuth client authentication and Flask session signing, the system inadvertently exposed the signing material to end users. This misconfiguration turned a standard web session mechanism into a vector for complete remote code execution on the server side.
What should you do?
Organizations should review their use of session signing keys and ensure they are never derived from or identical to other application secrets. Developers must avoid using unsafe deserialization methods like Python’s pickle for processing user-controlled or session-stored data. Teams should also verify that session cookies do not contain sensitive credentials or tokens that could be extracted and reused by attackers.
What to do and how to stay safe: Google
- Audit session management configurations to ensure signing keys are unique and never exposed in client-side data.
- Replace unsafe deserialization libraries with safer alternatives when processing serialized objects from sessions.
- Monitor server logs for unusual OAuth callback activities or unexpected code execution patterns.
- Verify that all developer-facing platforms have applied the latest security patches provided by their vendors.
Step-by-step guide: Social Engineering Warning Signs and How to Respond
General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which Google developer sites were affected by this vulnerability?
The flaw affected developers.google.com, firebase.google.com, developer.android.com, source.android.com, and docs.partner.android.com.
Why was the Flask session signing key exposed?
The OAuth client secret used for authentication also served as the Flask session signing key, and was stored in the cookie payload.
How did this lead to remote code execution?
Attackers could forge sessions containing malicious pickle objects, which were then executed by the server using Python’s pickle.loads() function.
