Threat reportVulnerabilityTL-2026-3355
Google DevSite Flask Session Pickle Deserialization RCE (Unauthenticated) - OAuth Client Secret Reused as Flask SECRET_KEY
Google DevSite Flask Session Pickle Deserialization RCE (TL-2026-3355) is a critical-severity software vulnerability, first published 2026-10-12. It has no confirmed attribution, affects Google DevSite documentation platform (developers.google.com, maps to 6 MITRE ATT&CK techniques (T1059.006, T1190, T1212), and is covered by 9 detection rules and 14 indicators of compromise.
- Severity
- CRITICALAssessed severity
- CVEs
- 0None referenced
- Techniques
- 6MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 14Indicators of compromise
Key facts for TL-2026-3355
- Threat ID
- TL-2026-3355
- Severity
- CRITICAL
- Status
- PATCHED
- Category
- VULNERABILITY
- First published
- Last reviewed
- Attribution confidence
- LOW
- Motivation
- UNKNOWN
- Target sectors
- technology, software-development, cloud
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 14
Malware and tooling in Google DevSite Flask Session Pickle Deserialization RCE
Malware and tooling: Python, curl, pickletools.dis
How Google DevSite Flask Session Pickle Deserialization RCE works
Researcher Simon Köck disclosed an unauthenticated remote code execution flaw in Google's DevSite documentation platform. The /oauth2authorize endpoint issued a Flask session cookie containing a pickled OAuth2WebServerFlow object with the plaintext client_secret, which was also the Flask SECRET_KEY, so an attacker could forge sessions carrying malicious pickle objects that the server unpickled. Google fixed it on 2026-10-07 and paid a $90,000 VRP reward.
DevSite is the shared documentation platform behind developers.google.com, firebase.google.com, developer.android.com, source.android.com and docs.partner.android.com. According to the researcher's write-up, the platform shared one signing key across seven Google domains (five are named in the sources; two are referenced but not listed).
The flaw was a chain of three weaknesses. First, an unauthenticated request to the /oauth2authorize endpoint (with a return_url parameter) returned a Flask 'session' cookie. The cookie used Flask's standard <payload>.<timestamp>.<signature> format and was zlib-compressed (leading dot in the payload, roughly 1,200 bytes). After decompression and base64 decoding it held JSON with '_permanent': true, a 'google_oauth2_csrf_token' and a 'google_oauth2_flow_<csrf>' entry whose ' b' key tagged a bytes value: a pickle-serialized oauth2client.client.OAuth2WebServerFlow object including the plaintext client_id and client_secret. Second, the client_secret was also used as the Flask SECRET_KEY: the signing key was derived with hmac.digest(client_secret, b'cookie-session', 'sha1') (itsdangerous key derivation) and the researcher reproduced the cookie signature byte-for-byte, so anyone who read the cookie could recover the key and sign arbitrary sessions - the signing key was stored inside the object it signs. Third, the OAuth callback called pickle.loads() on session data after the signature check, so a forged session containing a pickle payload (REDUCE opcode / __reduce__) ran attacker-chosen Python callables on the server.
The researcher proved code execution safely with time.sleep(N) payloads; response delay tracked the injected duration (sleep(0) 0.207s, sleep(3) 3.193s, sleep(5) 5.194s, sleep(8) 8.283s). Control tests: no cookie and a corrupted signature returned 'Invalid request'; flipping one signature character caused rejection while re-signing with the recovered secret was accepted; a valid signature with no flow entry returned 'Invalid request state'; a valid signature with a real OAuth flow reached token exchange and failed at authorization code validation. Tools used were curl, Python base64/json/zlib/hmac, pickletools.dis and a custom __reduce__ class.
Google triaged the report on 2026-08-07 and approved a $90,000 reward on 2026-08-27 ($75,000 base for Google Applications T2 severity with a 1.2x multiplier for report quality). The fix was deployed on 2026-10-07. Remediation required four changes: rotate the exposed OAuth credentials and invalidate sessions signed with them; use independent high-entropy SECRET_KEY values per instance; keep OAuth flow objects server-side with opaque session references in the cookie; and replace pickle with schema-validated data-only formats. No CVE, CVSS score, in-the-wild exploitation, threat actor or network IOCs are reported in the sources.
MITRE ATT&CK techniques used in TL-2026-3355
Execution
Initial Access
T1190 Exploit Public-Facing Application
Credential Access
T1212 Exploitation for Credential Access; T1552 Unsecured Credentials; T1606.001 Forge Web Credentials: Web Cookies
lateral-movement
T1550.004 Use Alternate Authentication Material: Web Session Cookie
Lateral Movement
T1550.004 Use Alternate Authentication Material: Web Session Cookie
Affected products and versions in Google DevSite Flask Session Pickle Deserialization RCE
- Google — DevSite documentation platform (developers.google.com, firebase.google.com, developer.android.com, source.android.com, docs.partner.android.com)
Vulnerable versions: Hosted service prior to 2026-10-07
Fixed in: Hosted service fix deployed 2026-10-07
Remediation for Google DevSite Flask Session Pickle Deserialization RCE
Patches
- Google deployed the fix on DevSite on 2026-10-07; no customer action is required for Google-hosted properties
Immediate actions
- Rotate any OAuth client secrets that were ever exposed in session cookies and invalidate all sessions signed with them
- Generate independent high-entropy SECRET_KEY values per server instance, decoupled from OAuth credentials
- Audit Flask applications for SECRET_KEY values that equal OAuth client secrets or other values present in client-visible data
Workarounds
- For self-hosted Flask apps with similar patterns, disable pickle-based session interfaces and force re-authentication after rotating keys
Longer-term hardening
- Keep OAuth flow objects server-side and store only opaque session references in cookies
- Replace pickle-based session serialization with schema-validated data-only formats such as JSON
- Add code review and SAST rules that flag pickle.loads() on request-derived data
Weaknesses (CWE) in Google DevSite Flask Session Pickle Deserialization RCE
Timeline of Google DevSite Flask Session Pickle Deserialization RCE
- Simon Köck submitted the report to Google's Vulnerability Reward Program (22:48).
- Google accepted the report as a valid vulnerability (16:23).
- Google triaged the report (08:12).
- Google approved a $90,000 reward: $75,000 base for Google Applications T2 severity with a 1.2x multiplier for exceptional report quality.
- Google deployed the fix (15:20): OAuth credentials rotated, sessions invalidated, independent signing keys and removal of pickle-based session handling.
- Public write-up published by the researcher and covered by GBHackers.
Sources cited for Google DevSite Flask Session Pickle Deserialization RCE
- How I Found a $90,000 Remote Code Execution Vulnerability in Google
- Critical Google DevSite Flaw Allowed Attackers to Execute Remote Code Without Authentication
- Google Vulnerability Reward Program
- Python pickle module documentation (security warning)
- Flask sessions documentation
- CWE-502: Deserialization of Untrusted Data
Detection coverage for TL-2026-3355
As of 2026-10-12, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-3355 across Splunk SPL, Microsoft KQL and Sigma, covering 14 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.