Critical Security Flaw in Google’s DevSite Exposed Risks of Remote Code Execution
A serious security vulnerability has been identified in Google’s shared DevSite platform, raising significant concerns regarding the potential for unauthenticated attackers to execute arbitrary code on services hosted by Google. The root of this issue lies in the ability to forge Flask session cookies enriched with malicious Python pickle payloads.
Simon Köck, a security researcher, uncovered this flaw while meticulously analyzing the OAuth authorization workflow utilized by Google’s various developer documentation platforms. This comprehensive assessment revealed vulnerabilities that affected not only developers.google.com but also several other Google domains, including Firebase, Android Developer, Android Open Source Project, and Partner Android documentation sites.
In an impressive display of responsiveness, Google addressed the vulnerability on October 7, 2026, and subsequently rewarded Köck with $90,000 through its Vulnerability Reward Program.
The Mechanics of the Attack
The attack vector commenced with a request directed at the unauthenticated /oauth2/authorize endpoint on developers.google.com. In response, this endpoint delivered a Flask session cookie that exceeded the expected size, leading to significant security implications.
Flask’s client-side session cookies are crafted to ensure integrity through signing; however, they are not encrypted by default. Upon decoding the compressed payload, Köck was able to detect that the session contained a serialized OAuth flow object, which included sensitive Google OAuth credentials such as the client_id and client_secret.
What’s more alarming is that the vulnerabilities extended beyond mere credential exposure. The OAuth client secret was undesirably utilized as the Flask SECRET_KEY responsible for signing the session cookies. This reuse mechanism meant that an attacker who successfully retrieved the client secret would be in a position to generate valid signatures for any arbitrary session content. Consequently, the application could not differentiate between a legitimate cookie issued by Google and a malicious one engineered by an attacker.
The vulnerable callback processing path accessed the OAuth flow object from the signed session, performed Base64 decoding on its value, and then transferred it to Python’s pickle.loads() function for deserialization.
Risks Associated with Unsafe Deserialization
The utilization of pickle for deserialization can be particularly risky when it involves untrusted data sources. A maliciously constructed object may be crafted to execute arbitrary Python functions during the deserialization process. Under normal circumstances, the integrity of the signed Flask cookie prevents users from altering the serialized object. However, the exposure of the signing secret effectively nullified this trust boundary.
An attacker could deftly forge a session containing a controlled pickle object and a corresponding CSRF state value. Upon receiving the request, the server would validate the forged signature, retrieve the malicious object, and proceed to deserialize it. Although the researcher did not execute any system commands within Google’s production environment, the proof of concept conducted involved utilizing time.sleep() payloads. This led to delays in server responses that were determined by the attacker, typically around three, five, and eight seconds, thereby showcasing that the supplied Python function had indeed been executed.
Widespread Implications of the Flaw
The magnitude of the issue is underscored by the fact that it was not restricted to a single documentation site. The flawed session-signing configuration applied across Google’s DevSite infrastructure meant that the compromised secret had the potential to create valid sessions for at least seven different Google domains, including:
- developers.google.com
- firebase.google.com
- developer.android.com
- source.android.com
- docs.partner.android.com
This alarming reality allowed an unauthenticated attacker to initiate the OAuth flow, recover the signing secret from a returned cookie, forge a malicious replacement, and execute server-side code without needing a Google account.
Köck first brought this vulnerability to Google’s attention on August 6, 2026. The company triaged the report promptly, accepting it on the same day, and decided on the substantial monetary reward of $90,000 by August 27. The full remediation of the vulnerability was deployed by October 7.
This incident serves as a stark reminder of how a combination of various missteps—such as the exposure of sensitive secrets, the reuse of keys, ineffective management of client-side state, and unsafe deserialization practices—can culminate in a catastrophic security chain that leaves systems vulnerable to unauthenticated remote code execution (RCE).
Organizations must remain vigilant in their defense strategies to mitigate the emergence of such vulnerabilities, emphasizing the importance of secure coding practices and robust management of sensitive credentials.