02.08.2024
2 min
1266
Cybersecurity researcher Simon Köck discovered a serious flaw in Google DevSite, a platform used to host developer documentation. Due to improperly secured session cookies, attackers could potentially forge sessions and execute arbitrary code on the company’s servers without logging into an account. The vulnerability affected multiple Google resources, including Android and Firebase documentation.
The issue was discovered during an examination of the OAuth authentication mechanism on developers.google.com. The researcher noticed a session cookie generated when navigating to Google’s login page. At approximately 1,200 bytes, it seemed unusually large for data that was supposed to contain only a security token and a redirect URL used after authentication.
Köck decided to inspect the cookie’s contents and discovered that Flask, the web framework used by the platform, digitally signed session data but did not encrypt it. This meant the cookie’s contents could be read without knowing the secret key.
Inside, the researcher found a serialized Python object containing an OAuth client ID and client secret. Most concerning was the fact that the platform used this same secret as the key for signing session cookies.
In his technical report, the researcher explained that he tested the exposed secret as the Flask SECRET_KEY and successfully verified the signature.
“I tried using the client secret as the Flask SECRET_KEY, and the issued cookie’s signature verified successfully. The signing key was stored inside the very object it was signing,” Köck wrote.
Essentially, the session protection mechanism had become ineffective. With the secret key, an attacker could create their own cookies, modify their contents, and generate valid signatures. Google’s server would then accept those cookies as legitimate.
The exposure of the secret key alone was not enough to execute arbitrary code. However, further investigation revealed that the OAuth callback mechanism used the pickle.loads() function to deserialize data retrieved from session cookies.
Python’s pickle module is designed to store and restore objects, but it has an important characteristic: deserialization can execute program code. As a result, processing attacker-controlled data through pickle creates a risk of remote code execution.
Köck combined the two flaws into a single attack chain. First, he used the exposed secret to create a forged session cookie with a valid signature. He then embedded a specially crafted Python object inside it. When processing the OAuth callback, the server verified the signature, accepted the session data, and passed it to the deserialization mechanism.
This made unauthenticated remote code execution (RCE) possible. An attacker did not need a Google account or access to the company’s internal infrastructure.
To demonstrate the issue, Köck chose not to execute arbitrary system commands on Google’s production servers. Instead, he created a test payload that called Python’s time.sleep() function, causing the server to pause execution for a specified number of seconds.
The results showed a clear correlation between the value embedded in the forged cookie and the server’s response time. When the researcher specified a three-second delay, the response arrived after approximately 3.19 seconds. A five-second delay produced a response time of around 5.19 seconds, while an eight-second delay resulted in 8.28 seconds.
Köck also performed control tests to rule out random network or server delays. Requests without a cookie or with an invalid signature were rejected, while a specially crafted cookie with a valid signature produced the expected delay.
“The response time matched the number specified in the pickle,” the researcher noted.
This confirmed that the server was actually executing the supplied code during deserialization rather than merely accepting a forged session.
The issue was not limited to developers.google.com. The vulnerable mechanism was used across the shared DevSite platform, which powers several Google developer documentation websites.
During testing, Köck confirmed that the same key could be used to create valid sessions on other Google resources, including:
This meant that a flaw in a single authentication component could potentially affect several of the company’s websites. However, the researcher’s report documents the technical feasibility of exploitation rather than confirmed attacks against these resources.
Köck reported the vulnerability to Google on August 6, 2026. The company reviewed and accepted his report the following day. On August 27, the researcher was awarded $90,000 through Google’s Vulnerability Reward Program.
According to the published timeline, the base reward for the unauthenticated remote code execution vulnerability was $75,000. Google increased the amount by 20% in recognition of the exceptional quality of the submitted report.
The issue was fully fixed on October 7, 2026. The researcher thanked the Google Bug Hunters team and DevSite engineers for investigating and resolving the vulnerability.
In his report, Köck also outlined measures to prevent similar attacks. These included rotating compromised OAuth secrets, using separate signing keys for each deployment, storing OAuth objects on the server instead of inside cookies, and avoiding pickle when processing client-supplied data.
