Google's PageBreak Reports 500 XSS Flaws, and Every Reported One Was Proven
Google described PageBreak in a post on its security blog by information security engineer Michał Bentkowski. The company says that "we have run PageBreak on a massive scale and it uncovered over 500 Cross-Site Scripting (XSS) vulnerabilities across Google first-party web applications (even on sensitive domains)." H2S Media and Superpower Daily both covered the disclosure the following day. Their reporting repeats Google's figures and doesn't add independent measurements, so the numbers here are Google's own.
The 500 figure counts bugs found. It does not count breaches. Google gives no breakdown by application, severity, fix date, or evidence of exploitation in the wild. Readers should treat it as a sign of the tool's reach, not as 500 incidents.
The timeline is short. According to Superpower Daily's summary of Google's account, PageBreak began as a pilot in November 2025 and became a full project in January 2026. Google says the agent works with different models, but most of its usage runs on Gemini 3.1 Pro or Gemini 3.5 Flash. That describes Google's own deployment. It is not a benchmark or a recommendation for anyone else.
XSS is the bug class the story centres on. In an XSS flaw, an attacker gets their own JavaScript to run in the context of a trusted site. That can mean stealing session data or taking actions as the victim. The class is old and well understood, yet it keeps turning up at scale inside one of the best-resourced security organisations in the industry.
PageBreak Answers "AI Slop" With Validators Written Without AI
Google is unusually blunt about the problem PageBreak was built to solve. The post says many security teams are overwhelmed because a significant portion of the candidate reports they receive is "AI slop" – noisy, unverified hypotheses or false positives generated by LLMs acting as static code analyzers. A static code analyzer reads source code and guesses where bugs might be without running anything. Google adds that distinguishing a genuine, exploitable flaw from a convincing hallucination has become a major challenge, often increasing the burden on product teams.
PageBreak's answer is what Google calls deterministic validation. When the agent suspects a flaw, it passes the idea to a specialised validator, and the validator runs a real payload against a live environment to confirm the exploit. Superpower Daily notes that Google says the validators are specialized tools, not code written by the AI agent. In practice the model proposes, and ordinary software decides whether the bug is real.
Google gives these examples of how the validators work for each bug class:
| Vulnerability class | How the validator proves it |
|---|---|
| Cross-site scripting (XSS) | Injects a specific JavaScript payload, loads the URL in a rendering harness or scanner, and watches whether the script actually runs |
| SQL injection | Injects payloads and checks whether the database query's output or timing changes |
| Path traversal | Creates a new file in a world-readable location and checks whether the application can read it |
| Remote code execution (RCE) | Tries techniques such as a sleep delay, writing a file to a world-writable location, or triggering outbound DNS/HTTP requests |
| Server-side request forgery (SSRF) | Detects whether the application triggers a request to an internal backend service it shouldn't reach |
Google says the validation logic and interface change with the bug class and with the application surface, such as HTTP or gRPC. The table covers Google's published examples. It is not a full list of what PageBreak can test.
Google says the approach gives it a "near-zero false positive rate." The post gives no percentage, sample size, or outside evaluation behind that phrase. It is a vendor description, not a measured rate.
What PageBreak's Unverified Findings Reveal About False Negatives
Proof-first reporting has a cost, and Google acknowledges it. Superpower Daily sums up both sides: Google reports a near-zero false-positive rate for sent findings, but acknowledges validators can miss real flaws they cannot test. If no validator exists for a bug type, or a scenario is too complex for the existing ones, a real vulnerability can go unconfirmed. A clean PageBreak report therefore says little about which bugs were missed.
Google doesn't throw those unconfirmed findings away, and it doesn't pass them to product teams either. PageBreak keeps findings it cannot verify as leads for later scans and for improving its validators, but does not send those candidates to product teams. Google describes three internal uses:
- Unconfirmed findings seed deeper inspection in later scans.
- They show where the automated validators fall short, which guides work on new validators.
- The agent reports what capabilities or environment access it was missing, so it effectively files feature requests against its own tooling.
The design also admits that models are unreliable over long tasks. Google says that even with specialised tooling, LLMs are increasingly adept at identifying complex vulnerability chains but can still go down unproductive paths. So it runs agents with identical seeds across many iterations to raise the odds that one run finds a working exploit. The post doesn't say how many runs are used or how much the repetition helps, which makes compute cost the biggest unknown for anyone budgeting a similar setup.
Google's High-Assurance Web Frameworks Held Up Against PageBreak
The comparison sits in the second half of Google's post. The company points back to a 2025 post on its high-assurance web framework approach, which it says is designed to systematically eliminate exploitable web vulnerabilities by default. It then reports that as of September 4, 2026, the scanner identified only 2 XSS vulnerabilities across hundreds of web applications built on these frameworks and those were limited to internal applications or debug endpoints with hardening gaps. Google's conclusion is that this real-world validation underlines the immense value of a safe-by-design framework-based approach to building secure software.
H2S Media goes further: "Same scanner, same company, same year. The difference was how the applications were built." That fits Google's own reading, but the numbers can't carry the claim alone. The 500-plus figure covers Google's first-party web applications in general, and Google doesn't say how many apps that is. The two-bug figure covers "hundreds" of framework-based apps. Without matched denominators you can't compute comparable bug rates. The two groups may also differ in age, exposure, and complexity. This is an observational comparison, not a controlled experiment.
Even with that caveat, the direction is clear and it fits how the frameworks are meant to work. An agentic attacker scanned apps from both groups, and the framework-based ones offered very few openings. The two it found were in internal tools or debug endpoints, the kind of code that tends to sit outside the hardened path. H2S Media's line that building on such a framework is "a considerably cheaper way to not have them" is editorial judgment. Google didn't publish cost figures. The judgment is still reasonable: stopping a bug class once in shared framework code costs less than finding, proving, triaging, and fixing hundreds of instances one by one.
Why PageBreak Depends on Google's Monorepo, Security Signals, and Scanners
Google is candid that much of PageBreak's success comes from infrastructure other organisations don't have. The model is only one part of the system. The post names three advantages.
The first is the monorepo. Because billions of lines of code live in one repository, the agent can follow complete execution paths end to end without consulting outside sources, and that includes service configurations. Google says a service misconfiguration was behind a cache-poisoning XSS it covers in a companion post on its Bug Hunters blog.
The second is Security Signals. Google says by leveraging security-relevant data extracted directly from live HTTP traffic, the agent can map HTTP paths to specific lines of source code, enabling it to discover and explore expanded attack surfaces. Linking a live URL to the code behind it is hard to do when source, deployment, and traffic data sit in separate systems owned by separate teams.
The third is existing scanner infrastructure. PageBreak repurposes Google's established suite of web application scanners to execute targeted security checks. Google says one scanner, built out over many years, can authenticate to nearly every Google web application. That lets PageBreak test internal sites that would otherwise be hard to scan, or that most security engineers couldn't even reach. H2S Media dates this scanning stack to "at least 2014." Google's post doesn't give that date and says only "many years."
For an enterprise security team, this is the most useful part of the post. An organisation without a unified codebase, without traffic-to-source mapping, and without authenticated scanning across its internal apps won't get PageBreak-like results by pointing a frontier model at a Git repository. It is more likely to get the noisy hypotheses Google complains about.
CodeMender Is Google's Answer to the Next Bottleneck
Verified findings still pile up. Google says that even though PageBreak reports only high-confidence, verified vulnerabilities, product teams face an unprecedented volume of reports. Its response is to link PageBreak with other agentic projects at Google, including CodeMender, which generates automated bug fixes. Google plans to deepen that integration until product teams mainly just validate proposed fixes.
This is a direction of travel, not a shipped result. The post doesn't claim autonomous patching has cleared the backlog or removed human review. H2S Media describes the dynamic plainly: "Agentic scanning finds more than people can fix, which creates a bottleneck one step further down the line, and the proposed solution is another agent."
The framework figure matters here too. Every XSS bug that a safe-by-default framework prevents never has to be found, proven, filed, or patched. It adds nothing to the backlog that CodeMender is meant to clear.
Where AI Scanning Fits in Your AppSec Budget
The PageBreak disclosure should change how you judge AI security tools and how you split spending between finding bugs and preventing them. Anyone running web applications, whether on Azure, on-premises IIS, or anywhere else, can draw lessons from Google's account. They are lessons about design, though, not a product you can adopt. PageBreak is internal to Google and isn't offered to customers.
If you're weighing an AI code-scanning product, the question Google's account raises is whether the tool proves its findings against a running system or just flags code patterns. Proof-of-exploit validation is what separates PageBreak from the "AI slop" Google describes. A tool that can't show an executed payload, a changed query result, or a triggered outbound request leaves your developers with the verification work.
Also ask what a tool misses. Google says openly that its validators don't cover every vulnerability type, so a quiet report from a validation-first scanner doesn't mean the app is clean. Traditional testing, code review, and penetration testing still have a place.
The framework result argues for moving effort toward prevention. Google's own inference is that building on frameworks designed to eliminate vulnerability classes by default paid off when an automated attacker tested them. Even there, the gaps were in internal apps and debug endpoints. Those are worth auditing in any organisation because they often skip the hardening applied to production-facing code.
- PageBreak is an internal Google tool, not a product you can buy or deploy.
- Google reports more than 500 verified XSS findings across its first-party apps but gives no severity breakdown or exploitation data.
- As of September 4, 2026, apps on Google's high-assurance frameworks produced only two XSS findings, both in internal apps or debug endpoints with hardening gaps.
- The "near-zero false positive rate" is Google's description, with no published percentage, and Google admits its validators can miss real bugs.
- Much of PageBreak's success comes from Google's monorepo, Security Signals traffic mapping, and long-established authenticated scanners, and most organisations lack all three.
- Internal tools and debug endpoints should get the same hardening as production code, because that's where Google's framework-based apps still had bugs.
Google has shown that AI-driven vulnerability discovery can work at large scale when every finding has to survive a deterministic test. The best result in the same post came from the apps where the scanner had almost nothing to find. As Google connects PageBreak to CodeMender and tries to reduce human work to approving fixes, the framework numbers will likely age better than the headline count: preventing a bug class in shared code creates less work than any agent can clear afterwards.