Full Report
While setting up Gemini Code Assist tools for personal use, they noticed that the State parameter on the OAuth Authorization flow contained an origin key. This key was used to verify the target origin of post messages, ensuring that only authorized domains request information via post messages. So, a very security-sensitive value. The domain check was flawed. Notably, it assumed that only a domain string was being passed and nothing else. So, it only checks that the end of the string matches a set of allowlisted domains. By using a path with an allowlisted domain and an attacker-controlled URL, the origin validation could be bypassed. For example, https://attacker.com/codeassist.google.com. The result is the stealing of an Authorization code for Gemini Code Assist end users. To fix the issue, the origin was treated as a URL with strict validation. Overall, a solid bug in a weird section of code.
Analysis Summary
# Vulnerability: PostMessage targetOrigin Bypass in Gemini Code Assist OAuth Flow
## CVE Details
- **CVE ID**: Not explicitly assigned (Google VRP typically tracks via internal bug IDs; however, this is a critical OAuth bypass).
- **CVSS Score**: Estimated 8.3 (High)
- **CWE**: CWE-346: Origin Validation Error
## Affected Systems
- **Products**: Google Gemini Code Assist tools (specifically the web-based OAuth authorization component).
- **Versions**: All versions prior to the July 2024 fix.
- **Configurations**: User accounts attempting to authorize Gemini Code Assist extensions or tools via the OAuth web flow.
## Vulnerability Description
The flaw resides in the validation logic for the `targetOrigin` used during `postMessage` communication in the OAuth flow. The `State` parameter in the OAuth Authorization flow contained an `origin` key intended to verify the destination for sensitive post-message data.
The validation routine incorrectly assumed the input would be a simple domain string. Instead of performing an exact match or properly parsing the string as a URL, the code only verified that the **end of the string** matched a list of allowlisted Google domains (e.g., `codeassist.google.com`). An attacker could bypass this by providing a URL where the "path" or "userInfo" component contained the allowlisted domain, such as `https://attacker[.]com/codeassist.google.com`.
## Exploitation
- **Status**: Disclosed via Bug Bounty (Fixed); No evidence of exploitation in the wild.
- **Complexity**: Medium (Requires the victim to initiate an OAuth flow).
- **Attack Vector**: Network (Web-based/Cross-site).
## Impact
- **Confidentiality**: High (Allows for the theft of OAuth Authorization codes, granting access to the user's Gemini Code Assist environment).
- **Integrity**: Medium (Potential unauthorized actions on behalf of the user).
- **Availability**: Low.
## Remediation
### Patches
- **Google Server-side Fix**: Google has updated the validation logic to treat the `origin` as a full URL object. Strict validation is now enforced to ensure the hostname matches the allowlist exactly, rather than performing a suffix-based string match.
### Workarounds
- There are no client-side workarounds. Users should ensure they are using the latest versions of Gemini-related IDE extensions which interact with the updated Google backend.
## Detection
- **Indicators of Compromise**: Difficult to detect from the end-user side. Security teams should look for OAuth authorization requests where the `state` parameter contains an `origin` key pointing to untrusted or "stacked" domains (e.g., `[untrusted-domain]/[trusted-domain]`).
- **Detection Methods**: Monitoring web logs for anomalous redirect URIs or state parameters in OAuth flows.
## References
- **Vendor Advisory**: hxxps[://]bughunters[.]google[.]com/blog/6090766282358784/postmessage-targetorigin-bypass-opens-room-for-oauth-authorization-code-stealing-scenarios
- **OAuth Security Best Practices**: hxxps[://]datatracker[.]ietf[.]org/doc/html/rfc6749