Full Report
On the Google Cloud CLI gcloud, the authentication process works using OAuth and a server that is quickly setup on the computer at localhost:50000. This means that http://localhost is actually a valid redirect_uri on OAuth! Given that we have a browser parsing doing the redirect and a backend parser validating the redirect, this becomes the perfect chance to find an account takeover via an evil redirect. At first, this didn't make sense to me. Most of the time, these are static string checks and are an allowlist, giving very little wiggle room. The author of the post tried 127.0.0.1 and noticed that this worked. This meant that they were parsing the URL rather than just doing a static string check on the backend. With two parsers in play, it's time to find a difference! They wrote a Python script that performed a large amount of URL mutations. Encoding trips, private IPs, weird schemas, IPv6, etc. After running their fuzzing script for a while, they found a match: http://[0:0:0:0:0:ffff:128.168.1.0]@[0:0:0:0:0:ffff:127.168.1.0]@attacker.com/ This URL is super weird. The @ symbol is used as the separator between the username and the password on a URL. It's actually invalid to have two of them. Chrome mitigates this edge case by encoding all non-reserved characters and earlier occurrences of reserved characters. However, the parser on the backend likely ignored the attacker.com part of the URL and grabbed the proper data from the set positions. Neat! What's interesting is that this only happened when using IPv6. When using IPv4, this didn't work. A working redirect_uri is as follows: http://[::1]@[::1]@attacker.com. The server would parse the second [::1] as the server information and skip the attacker.com entirely. However, Chrome would parse attacker.com as the host. Mixing this with OAuth gave the author an arbitrary redirect to steal the OAuth to be logged into the users account. That's a pretty rad bug with good visuals and background.
Analysis Summary
# Vulnerability: Google Cloud Account Takeover via URL Parsing Confusion
## CVE Details
- **CVE ID:** Not explicitly assigned in the report (Referenced as a Google Bug Bounty finding).
- **CVSS Score:** Estimated 8.1 (High) - based on Account Takeover (ATO) potential.
- **CWE:** CWE-601: URL Redirection to Untrusted Site ('Open Redirect'); CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling/Confusion').
## Affected Systems
- **Products:** Google Cloud CLI (`gcloud`), Google OAuth 2.0 Authorization Server.
- **Versions:** Versions prior to the fix (April 2024/2025 timeframe).
- **Configurations:** Systems using loopback addresses (`localhost` / `127.0.0.1`) for OAuth redirection, specifically those supporting IPv6 notation.
## Vulnerability Description
The vulnerability stems from a "Parser Confusion" between how the Google OAuth backend validates a `redirect_uri` and how modern web browsers (specifically Chrome) interpret the same URI.
The `gcloud` CLI creates a temporary local server on `localhost:50000` to receive OAuth tokens. The Google backend validator permitted the use of IPv6 loopback addresses but used a parser that handled the `@` (userinfo) delimiter differently than the browser. By using multiple `@` symbols in an IPv6 literal format, an attacker can craft a URI that the backend perceives as a legitimate local loopback address, while the browser interprets the final segment as an external attacker-controlled domain.
## Exploitation
- **Status:** PoC Available / Validated via Bug Bounty Program.
- **Complexity:** Medium (Requires knowledge of URL parsing edge cases).
- **Attack Vector:** Network (Phishing/Social Engineering). An attacker tricks a victim into clicking a malicious OAuth authorization link.
- **PoC URI:** `http://[::1]@[::1]@attacker[.]com`
- **Backend Parser:** Sees `[::1]` (localhost) as the host, ignoring the rest as userinfo.
- **Chrome Browser:** Sees `attacker[.]com` as the destination host.
## Impact
- **Confidentiality:** High (Full access to the victim’s Google Cloud account and associated data).
- **Integrate:** High (Ability to modify cloud resources, delete data, or create backdoors).
- **Availability:** High (Potential for resource deletion or denial of service).
## Remediation
### Patches
- **Google Server-side:** Google updated their OAuth validation logic to strictly check loopback `redirect_uri` strings and handle IPv6/userinfo parsing more securely.
- **gcloud CLI:** Recommended to update to the latest version of the Google Cloud SDK.
### Workarounds
- **Manual Token Exchange:** Users can use the `--no-browser` flag with `gcloud auth login` to perform a manual copy-paste of the authorization code, bypassing the automated redirect.
## Detection
- **Indicators of Compromise:**
- OAuth audit logs showing successful authorizations with unusual `redirect_uri` parameters (containing `@` symbols or nested IPv6 brackets).
- Unrecognized sessions in the Google Cloud Console "Identity & Security" logs.
- **Detection Methods:** Monitor for OAuth flow requests where the `redirect_uri` contains an `@` sign while targeting `localhost` or `127.0.0.1`.
## References
- **Original Report:** hxxps://infosecwriteups[.]com/google-cloud-account-takeover-via-url-parsing-confusion-c5e47389b7c7
- **RFC 3986:** hxxps://datatracker[.]ietf[.]org/doc/html/rfc3986 (URI Generic Syntax)