---
id: 8799
canonical_url: "https://phying.com/item/8799"
source_url: "https://bughunters.google.com/blog/pagebreak-real-world-findings"
source_domain: "bughunters.google.com"
title: "Google's PageBreak Project – Real-World Findings"
type: "research"
severity: "unknown"
cve: null
published_at: "2026-09-24T00:00:00Z"
lang: "en"
---

# Google's PageBreak Project – Real-World Findings

> **Author**: Michał Bentkowski (on behalf of the PageBreak team, Google Information Security Engineer)  
> **Published**: September 24, 2026 | **Source**: [bughunters.google.com](https://bughunters.google.com/blog/pagebreak-real-world-findings)

This post provides a technical deep dive into specific, real-world vulnerabilities discovered by our PageBreak scanner. To learn more about how PageBreak works under the hood, check out our [companion post on the Google Security Blog](https://blog.google/security/agentic-hacks-real-proofs-inside-googles-pagebreak-project/).

Automated vulnerability discovery using LLMs often struggles with high rates of false positives and hallucinations. On the Google Security Blog, we recently introduced PageBreak, an internal project developed by Google's Product Security team to solve this exact problem. By prioritizing deterministic validation—where the agent executes real payloads to confirm an exploit against a running environment—PageBreak achieves a near-zero false positive rate.

In this post, we will look at what exactly happens when you point a highly capable, noise-free agent at real-world applications.

## Technical Case Studies

By combining agentic reasoning with live-site verification, PageBreak uncovered complex logic flaws that traditional scanners will often miss. Below are three examples of high-severity vulnerabilities PageBreak found in Google applications. Before being scanned by PageBreak, Google security engineers and external bug hunters had closely scrutinized these applications without discovering the issues PageBreak identified.

### Case 1: Cache Poisoning in apis.google.com

A cache poisoning vulnerability in the routing configuration of the static file server serving a JavaScript file on `apis.google.com` allowed attackers to add arbitrary code to JS files.

The server used a regular expression to parse incoming URLs and extract variables, including an unconstrained path segment (`extra_path`) between the base path and the filename. So if you load a URL such as `/js/hello/file.js`, then `/js/hello` is treated as an `extra_path`.

The unvalidated `extra_path` was directly concatenated into the JS returned by the server. For a request like `/js/"-alert(1)-"/api.js`, the extra `"-alert(1)-"` would end up in the static JavaScript file.

The issue that escalated this from a reflected injection (and potentially only a Content Security Policy bypass) into a cache poisoning was how the cache key for the JS was constructed. Namely, the cache key was built using the filename and other parameters, but the `extra_path` variable was completely omitted from cache key generation. Consequently, requests for the malicious path and the legitimate path generated the exact same cache key.

The underlying source file contained an assignment like `u:"%%URL%%"`. After the transformer completed the replacement, the cached JavaScript became `u:"https://apis.google.com/js/"-alert(1)-"/api.js"`. When loaded by a victim's browser, the syntax acted as a string breakout, executing the arbitrary JavaScript.

Because the `extra_path` was ignored during cache key generation, the attacker could poison the cache entry for the standard `api.js`.

It is important to note that the cache was not poisoned for all users globally, but rather restricted to those in the geographical proximity of the location where the attack was initiated. However, despite this limitation, this was still a high-risk vulnerability that could have resulted in cross-site scripting (XSS) across many sensitive Google domains and external ones relying on JS files from `apis.google.com`. No evidence has been found to indicate that real-world attackers have exploited this vulnerability.

### Case 2: XSS in admin.google.com

In the administrative console's endpoint (`/a/autodns/registrar`), there was an unverified `redirect_uri` parameter that was ultimately assigned to `window.location` within a `<script>` block. This lack of validation meant that an attacker could pass a malicious `javascript:alert(1)` payload to it to achieve arbitrary code execution in the browser.

This request, however, required a valid cryptographic signature supplied via the `sig` request parameter. Because an attacker generally lacks access to the correct key, they cannot generate a valid signature, leading the server to reject such requests and preventing the exploitation of this flaw.

Interestingly however, the agent was able to figure out how to bypass this protection by itself. It discovered that a valid signature for this malicious payload could be generated by leveraging another request in the flow.

By invoking the authorization endpoint (`/a/autodns/authorize`) with the malicious `javascript:` URI, the application would calculate a valid signature for the parameters using the same cryptographic key. The resulting redirection URL would contain a valid `sig` generated by the server for the malicious payload. An attacker could then extract this valid signature and use it to construct the final exploit URL, bypassing the cryptographic protection and ultimately achieving an XSS.

### Case 3: Insecure External Handshakes in Browser Extensions

A Universal Cross-Site Scripting (UXSS) vulnerability was identified in the [Tag Assistant Extension](https://chromewebstore.google.com/detail/tag-assistant/kejbdjndbnbjgmefkgdddjlbokphdefk?hl=en&pli=1). The flaw would allow an attacker to inject and execute arbitrary JavaScript on any page that the user visits, using Google Tag Manager (GTM). This vulnerability can be broken down as follows:

1. **Insecure External Connection**: The extension's background script listened for external connections using the `chrome.runtime.onConnectExternal` API. While the `externally_connectable` configuration restricted connections to Google-owned domains (e.g., `*.google.com`), the background script failed to strictly validate the specific origin of the sender within those domains. Consequently, an XSS vulnerability on any sub-domain of `google.com` could be leveraged to establish a connection to the extension.
2. **The Handshake and Nonce Exfiltration**: To inject a payload, an attacker would need to bypass a protection mechanism relying on a one-time `nonce`. The page script (GTM debug bootstrap) periodically sent `PING` messages to establish a connection. By responding to these heartbeats, the attacker could simulate the extension and force the page to emit a `CONTAINER_STARTING` message, which contained a valid `nonce` generated by the page.
3. **Message Forwarding and Unsafe Sink**: Once the attacker obtained the `nonce`, they could send a malicious `CONTAINER_DETAILS` message back to the extension. The extension blindly forwarded this message to the debugged frame.

The injected page script received this message, which contained a `scriptSource` property. This property was then loaded directly as a script without sufficient validation or sanitization. Because the application allowed arbitrary protocols, including `data:` URLs, the attacker could supply a payload like `data:text/javascript,alert(1)` to achieve arbitrary code execution in the context of the debugged page.

## Conclusion

We hope that the examples we shared above help underscore the value of scanners like PageBreak that unite agentic reasoning with live-site verifications. This approach allows discovering complex vulnerabilities while avoiding overburdening developers with large amounts of false positives and hallucinations.

---
> 📦 **Full-Text Markdown Snapshot** archived by [Phying News](https://phying.com/item/8799) · Original source: [bughunters.google.com](https://bughunters.google.com/blog/pagebreak-real-world-findings)