OAuth redirects https://notebooks.cloud.google.com/static/oauth.html and https://developerconnect.google.com/redirect appear to preform no protocol checks allowing for network attackers to leak tokens.
It’s a less cool https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2.1 variant of https://bughunters.google.com/reports/vrp/wG2bN8vZr for network attackers.
const ALLOWED_ORIGINS = [
'codeassist.google.com',
'pantheon.corp.google.com',
'pantheon-staging.corp.google.com',
'pantheon-staging-sso.corp.google.com',
'pantheon-hourly.corp.google.com',
'pantheon-hourly-sso.corp.google.com',
'console.cloud.google.com',
'code-assist-free-tier.corp.google.com',
'code-assist-free-tier-autopush.corp.google.com',
'code-assist-free-tier-staging.corp.google.com',
'localhost.corp.google.com:9998'
];
let origin = JSON.parse(
new URLSearchParams(window.location.search).get('state')
).origin;
let host = new URL(origin).hostname;
for (const allowedOrigin of ALLOWED_ORIGINS) {
if (host.endsWith(allowedOrigin)) {
window.opener.postMessage(window.location.toString(), origin);
window.close();
break;
}
}
Requirements:
- User trusts the Google Cloud Developer Connect Account Connector OAuth app on GitHub this has
Full control of private repositories
By following the normal HTTPS OAuth flow and redirection.At the time of report this could be done on https://codeassist.google.com/agents-tools but that feature has since gone.
- The user is on a public network.
User steps:
- User gets automatically redirected to an attacker captive portal (Normal secure non-google looking website)
- User taps accept cookies for popup (User activation)
Attacker script steps:
- That attacker page then does two things: it opens a popup and redirects the now hidden tab to
http://unsafe.codeassist.google.com/that’s over an insecure connection and controlled by the attacker. - Attacker controlled
http://unsafe.codeassist.google.com/uses its post message listener to steal the secret OAuth URL viawindow.onmessageGitHub doesn’t support the implicit grant type but it’s likely abused by using the https://codeassist.google.com/api/finishoauth method same as the previous VRP report.
- The popup gets redirected to the attacker modified OAuth URL with its custom
statevalue https://github.com/login/oauth/authorize?redirect_uri=https%3A%2F%2Fdeveloperconnect.google.com%2Fredirect&client_id=Ov23liuPPgjf25D65gXP&scope=repo&state=%7B%22origin%22%3A%22http%3A%2F%2Funsafe.codeassist.google.com%22%7DSince the attacker is not asking for any new permissions despite the URL parameters changing, this OAuth flow does not prompt the user for consent.
Reasoning for WONTFIX
“We’ve reviewed your report, and it seems the attack you’ve outlined relies on a few unlikely conditions. For this to work, a user would need to be on a malicious network and then actively click through redirects to an attacker-controlled site. We’re also not clear on how a user would initially be directed to this malicious website.
Given these factors, we won’t be tracking this as a security vulnerability.”
The Chromium team are planning on enabling HTTPS by default for Chrome 154 in October 2026 https://security.googleblog.com/2025/10/https-by-default.html
Time line
- Reported Sep 14, 2025 01:01 AM
- Didn’t provide enough details Sep 15, 2025 07:57 PM
- Assigned Sep 16, 2025 02:54PM
- Highly unrealistic preconditions. If an attacker had that level of access, they could likely achieve more significant compromises. Sep 20, 2025 12:12 AM
- Assigned Sep 22, 2025 01:45PM
- Reviewed by Trust & Safety Team Sep 24, 2025 02:18PM
- Changed from P3 to P2 Nov 4, 2025 09:18 PM (Thanks)
- Won’t Fix (Infeasible) Nov 5, 2025 09:59 PM