How a leaked secret let hackers run code on Google’s dev sites

The short version

• A vulnerability in Google’s DevSite platform allowed unauthenticated remote code execution via forged sessions.
• The root cause was an OAuth client secret being used as the Flask session signing key.
• The bug was resolved in October 2026 following responsible disclosure by Simon Koeck.

The details

According to researcher Simon Koeck, a flaw in Google’s shared DevSite infrastructure permitted attackers to execute remote code on multiple developer websites. The issue stemmed from how the platform handled Flask session cookies within its OAuth flow. These cookies were signed but not encrypted, meaning their contents remained readable to anyone who obtained one. Koeck discovered that the stored data contained a serialized OAuth object, which included both a client ID and a client secret.

The severity escalated when Koeck confirmed that this same client secret served as the SECRET_KEY for signing Flask sessions. This dual use meant that obtaining a single cookie revealed the secret needed to forge new, valid signatures. With that key, an attacker could create trusted session data that the server would accept without question, effectively bypassing the primary control against client-side tampering. This finding was reported to Google in August 2026.

The context

The risk of code execution arose from how the DevSite application processed the OAuth flow data stored in those sessions. The system reportedly Base64-decoded the information and passed it directly into Python’s pickle.loads() function. Python documentation explicitly warns that the pickle module is insecure and should only handle fully trusted data, as malicious payloads can execute arbitrary code during restoration.

By crafting a specific pickle object and embedding it in a forged session, an attacker could trigger this dangerous deserialization process. This chain affected several major domains, including developers.google.com, firebase.google.com, developer.android.com, source.android.com, and docs.partner.android.com. Google addressed the vulnerability on 7 October 2026 and awarded the researcher $90,000 through its Vulnerability Reward Program.

Next steps

Organisations should review their use of Flask or similar frameworks to ensure session signing keys are never derived from or identical to other credentials like OAuth secrets. Developers must avoid using pickle for deserialising any user-controlled or session-stored data. Regular audits of key management practices can prevent similar dual-use errors where one secret compromises multiple security boundaries.

What to do and how to stay safe: Google

• Audit your application to ensure session signing keys are unique and never reused as authentication credentials.
• Avoid using pickle or similar deserialisation libraries for data that originates from clients or sessions.
• Monitor for unexpected code execution or anomalous session behaviour on your web applications.
• Once the vendor provides an update, apply patches promptly to affected documentation or developer portals.

Step-by-step guide: Password Manager Security Checklist: Hardening Your Vault

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

Frequently asked questions

Which Google sites were affected by this vulnerability?

The flaw impacted developers.google.com, firebase.google.com, developer.android.com, source.android.com, and docs.partner.android.com.

Why was this flaw considered severe?

It allowed unauthenticated attackers to forge sessions and execute arbitrary code via insecure pickle deserialization.

Has the vulnerability been patched?

Yes, Google fixed the flaw on 7 October 2026 after receiving the report in August.