GBHackers

Critical Google DevSite Flaw Allowed Attackers to Execute Remote Code Without Authentication


A critical security vulnerability in Google’s shared DevSite platform could have let unauthenticated attackers execute arbitrary code on Google-hosted services by forging Flask session cookies with malicious Python pickle payloads.

Security researcher Simon Köck discovered the issue while analyzing the OAuth authorization workflow used by Google’s developer documentation properties.

The vulnerability affected the shared infrastructure behind developers.google.com and other domains, including Firebase, Android Developer, Android Open Source Project, and Partner Android documentation sites. Google addressed the issue on October 7, 2026, awarding the researcher $90,000 through its Vulnerability Reward Program.

Critical Google DevSite Flaw

The attack initiated with a request to the unauthenticated /oauth2/authorize endpoint on developers.google.com. This endpoint returned a Flask session cookie that was significantly larger than expected for an OAuth CSRF token and return URL.

Flask client-side session cookies are signed to ensure integrity but are not encrypted by default. After decoding the compressed payload, Köck found that the session included a serialized OAuth flow object containing Google OAuth client_id and client_secret values.

The core issue was even more severe than simply exposing OAuth credentials: the OAuth client secret was also reused as the Flask SECRET_KEY used to sign session cookies.

This reuse meant that an attacker who recovered the client secret could generate valid signatures for any arbitrary session contents. Consequently, the application could not distinguish a legitimate cookie issued by Google from a malicious cookie crafted by an attacker.

The vulnerable callback processing path retrieved the OAuth flow object from the signed session, Base64-decoded its value, and passed it to Python’s `pickle.loads()` function.

The use of `pickle` for deserialization presents risks when dealing with untrusted data because a crafted object may invoke Python functions during deserialization.

Under normal circumstances, the signed Flask cookie ensured users could not alter the serialized object. However, because the signing secret was exposed in the cookie, the trust boundary collapsed.

An attacker could create a forged session containing a controlled pickle object and a matching CSRF state value. When the server received the request, it validated the forged signature, retrieved the malicious object, and deserialized it.

While the researcher did not execute system commands in Google’s production environment, the proof of concept involved using `time.sleep()` payloads. The server delayed responses by attacker-chosen intervals, about three, five, and eight seconds, showing it executed the supplied Python function.

The vulnerability wasn’t limited to a single documentation site, as the flawed session-signing configuration was shared across Google’s DevSite platform. The recovered secret reportedly generated valid sessions for seven Google domains, including:

  • developers.google.com
  • firebase.google.com
  • developer.android.com
  • source.android.com
  • docs.partner.android.com

This made the issue particularly serious: an unauthenticated attacker could initiate the OAuth flow, recover the signing secret from a returned cookie, forge a malicious replacement, and trigger server-side code execution without needing a Google account.

Köck reported the flaw to Google on August 6, 2026. Google triaged the report the next day, accepted it on the same day, and decided on a $90,000 reward on August 27. The final remediation was deployed on October 7.

This case underscores how individually dangerous mistakes, such as secret exposure, key reuse, client-side state management, and unsafe deserialization, can converge into an unauthenticated remote code execution (RCE) chain.

Stops Cyber threats before impact with 21 min faster MTTR. Integrate ANYRUN’s Sandbox in your SOC.



Source link