Google's developer servers could be made to execute code without an attacker signing in.
Security researcher Simon Köck discovered a vulnerability in Google's DevSite platform that exposed an authentication secret and allowed attackers to forge trusted sessions. Combined with unsafe data processing, the flaw could enable remote code execution on the server.
Google has since fixed the issue and awarded Köck $90,000 for the discovery. The case highlights how two security weaknesses can combine to turn an exposed credential into a much more serious compromise.
A cookie carried the key used to verify it
While examining the OAuth sign-in process on developers.google.com, Köck noticed a Flask session cookie roughly 1,200 bytes long. Visitors received it before being redirected to Google's sign-in page.
According to Köck, the decoded cookie contained an OAuth client ID and client secret. In DevSite's implementation, the exposed secret could also be used to sign Flask session cookies, allowing an attacker to create cookies the application would accept as valid.
A separate flaw existed in the OAuth callback. It used Python's pickle.loads() to reconstruct an object stored in the session, a process that can run attacker-controlled instructions through unsafe deserialization. Forged cookies could therefore carry malicious instructions into the function.
To test the vulnerability without executing operating system commands, the researcher prepared time.sleep() payloads. Server responses were delayed by approximately three, five and eight seconds, matching the requested timings. Cookies with altered signatures were rejected, supporting his finding that the server had executed the test functions.
Four other developer sites accepted forged sessions
Further testing found that the recovered key worked on four additional properties. Valid sessions were accepted on firebase.google.com, developer.android.com, source.android.com, and docs.partner.android.com. Köck did not document separate code execution tests for each host.
Google awarded Köck $90,000 after classifying the vulnerability as an S0 remote code execution issue. DevSite engineers completed the fix on Oct. 7, ahead of public disclosure.
Köck reported that the exposed OAuth client secret was still active when he prepared his disclosure, although he withheld its value.
Google has not publicly detailed the remediation steps described in his account, so it is unclear whether the fix involved changing session handling, removing unsafe deserialization, or other measures. The credential's reported status does not establish that the original attack remained exploitable.
Security teams should review their own session handling
The vulnerability was specific to Google's DevSite implementation, but it highlights security risks that can affect other web applications.
Developers should review how their applications store session data and handle information received from browsers. Signed cookies can protect against unauthorized modification, but they do not necessarily encrypt their contents or make unsafe deserialization secure.
Security teams should prioritize several checks:
- Inspect session cookies for exposed credentials. Check what information your applications make accessible to browsers and remove embedded secrets. Include these checks in regular application security reviews, particularly for internet-facing services.
- Find unsafe data processing. Examine code that reconstructs objects from information users can influence, particularly functions such as pickle.loads(). Replace risky deserialization paths with validated data formats or server-side records.
- Review shared authentication credentials. Identify websites that reuse signing keys or other security-sensitive credentials. Use separate keys where appropriate and establish procedures to rotate exposed secrets and invalidate affected sessions.
- Test exposed endpoints and restrict application privileges. Include requests made before login in web application security testing, alongside code reviews. Limit permissions granted to application processes to reduce potential access to sensitive business information or connected systems.
The DevSite case shows how weaknesses that appear manageable in isolation can become far more dangerous when combined. For developers, securing authentication means protecting not just the login process but also the data applications trust after a session is established.
More cybersecurity news: SonicWall customers faced a narrow patching window after attackers began exploiting a critical flaw within 48 hours of disclosure.