Google's Threat Intelligence Group (GTIG) says it has, for the first time, seen a threat actor use a zero-day exploit it believes was built with the help of an AI model. The exploit was a Python script that bypassed two-factor authentication on an open-source administration tool. Google withheld both the actor and the product to protect the fix.
The headline writes itself, but it points the wrong way. The real shift is not smarter phishing or better-written lures. It is exploit-cycle compression: AI is collapsing the time and skill it takes to find a vulnerability and turn it into a working exploit. For anything as large and as exposed as a web browser, that changes the math.
What Google actually found
GTIG's report, published on 2026-05-11, is careful about what it claims. It does not say AI wrote the exploit. It says Google has high confidence, based on the code's structure, that the actor used an AI model to help discover and weaponize the bug. The tells were in the source: textbook docstrings, an oddly tutorial-like Pythonic layout, and a hallucinated CVSS score that no human researcher would invent. Google also notes that its own model, Gemini, was likely not the one used.
The same report describes three other patterns worth separating from the hype:
- AI-assisted exploit generation, where models speed up the research and weaponization rather than replace the attacker.
- More autonomous malware, still experimental, where a payload queries a model at runtime to read system state and pick its next action instead of following hardcoded logic. Google points to research-stage families such as PROMPTSPY and PROMPTFLUX.
- Industrialized abuse of premium model access, where criminals use middleware and automated sign-up pipelines to get around usage limits.
None of this is "AI replaces hackers." It is "AI makes the slow, expensive parts faster." That is the part defenders should plan around.
The real shift is exploit-cycle compression
Finding a serious vulnerability and writing a reliable exploit has always been the expensive part of an attack. It takes rare skill, time, and patience. Phishing copy was never the bottleneck.
Compression attacks that bottleneck. When a model helps a mid-tier actor read unfamiliar source, spot a weak code path, and scaffold a working proof of concept, the gap between "a bug exists" and "a bug is being exploited at scale" gets shorter. Google's case is one data point. The trend line is the story: faster research, faster weaponization, higher operational tempo.
That matters most for software that is huge, fast-moving, and everywhere. The browser is the clearest example.
Why the browser is the biggest target
Browsers are vast, multi-component systems
A modern browser is not one program. Chromium, the engine behind Chrome, Edge, Brave, Opera, and many others, runs to tens of millions of lines of code and pulls in more than 200 third-party libraries. Many of them are open source and maintained by separate teams:
- V8 runs JavaScript and WebAssembly.
- Blink renders the page.
- Skia draws 2D graphics.
- ANGLE translates graphics calls for the GPU.
- libwebp decodes WebP images.
- WebRTC handles real-time audio and video.
Every one of those is attack surface. A single memory bug in any of them can become remote code execution. Open source is a strength for review and speed, but it also means the exact code an attacker studies is the same code shipping to billions of devices.
New features ship constantly, and new zero-days follow
Chrome ships a new milestone roughly every four weeks, and the web platform keeps growing: new APIs, new codecs, new GPU paths. More features mean more code, and more code means more bugs. The result is steady, not occasional. Google patched around nine actively exploited Chrome zero-days in 2024 and around eight in 2025, and they cluster in the same complex components:
- V8 type confusion: CVE-2025-10585 and CVE-2025-13223.
- ANGLE and GPU validation: CVE-2025-6558.
- Skia and V8 again in 2026: CVE-2026-3909 and CVE-2026-3910, both exploited in the wild.
Zero-days in the browser are not rare events to brace for. They are a recurring condition to design around.
One open-source component, cross-ecosystem blast radius
The clearest warning came from libwebp. CVE-2023-4863 was a heap buffer overflow in that one image-decoding library, exploitable with a single crafted WebP file. It was first scored 8.8 as a Chrome bug, then re-rated 10.0 once the scope was understood, because libwebp is everywhere. (A second identifier, CVE-2023-5129, was later folded in as a duplicate.)
The same bug hit Chrome, Firefox, Signal, 1Password, Telegram, and, critically, nearly every application built on Electron. One library, one flaw, and the blast radius covered a large slice of the software people use every day.
Zero-days don't stop at the browser tab
Here is where compression gets dangerous. The browser sandbox exists for a reason: a tab is supposed to be a hostile environment, walled off from the rest of your machine. But the same engine that powers your browser also ships inside desktop apps.
Electron bundles its own copy of Chromium so web developers can build native-feeling apps. VS Code, Slack, Discord, and Anthropic's Claude desktop app are all Electron applications. Each carries its own Chromium build, and those builds lag upstream. When Google patches a V8 zero-day, every Electron app stays vulnerable until it pulls in the fix and ships an update, which can take weeks.
Now combine two facts. First, these apps inherit the browser's zero-days. Second, they run outside the browser sandbox, often with full filesystem access, and in the case of AI coding agents, the ability to run shell commands. A browser-engine bug that would be a contained, sandboxed problem in a tab becomes far more serious inside a local app that can read your files and execute code. The libwebp case already proved Electron apps inherit these flaws. As AI desktop apps and coding agents spread, the population of high-privilege, Chromium-bearing software on developer machines keeps growing, and so does the payoff for a single browser-engine zero-day.
Poisoned dependencies execute in the same browser
Compression has a second front: the supply chain. The same AI that accelerates exploit research accelerates finding and abusing weak dependencies, and dependency code runs in the exact place you cannot see from the server.
The npm ecosystem made this concrete in 2025. On 2025-09-08, attackers phished a maintainer and pushed malicious versions of hugely popular packages, including chalk and debug. The injected payload was a browser-targeted crypto-clipper: it hooked window.ethereum and network calls to silently swap wallet addresses in the victim's browser. Days later, the self-replicating "Shai-Hulud" worm compromised hundreds of packages and stole developer credentials as it spread.
This is the Magecart pattern generalized. Malicious third-party code does not need a memory bug. It just needs to load, and once it does, it runs in the same context as your page, with access to forms, tokens, and everything the user types.
Why pre-release scanning isn't enough
Most security budgets still sit before deploy: static analysis, dependency scanning, a review gate, then ship. Those controls are necessary, but they share one blind spot. They inspect a snapshot of code you already know about, at a moment before it runs.
Zero-days are, by definition, the bugs nobody has catalogued yet. Compromised dependencies often change after they pass review, swapping clean code for malicious code on a later load. Third-party scripts update themselves in production without asking. And exploit-cycle compression shortens the window between a flaw becoming known and a flaw being used. Scanning a pre-release snapshot cannot catch a payload that only appears at runtime, in the browser, after your pipeline is done.
That gap is not a tooling failure. It is a visibility failure. You cannot scan your way to seeing what executes in someone else's browser session.
What to do this week
- Inventory every third-party script on your site, including the ones loaded by other scripts.
- Monitor script behavior at runtime, not just at deploy: what loads, what changed, what each script reads, and where it sends data.
- Tighten patch cadence for browsers and for Electron apps your team runs. Treat a Chromium zero-day as a deadline for VS Code, Slack, and similar tools, not just for the browser.
- Enforce a Content Security Policy that limits where scripts can load from and where data can be sent.
- Alert on anomalies: a known script suddenly contacting a new domain, reading payment fields, or changing its payload.
How cside fits
cside watches the layer the rest of your stack cannot: the live browser session. It gives you runtime visibility into every script that executes on your site, what it loads, how it changed since the last version, what data it touches, and where that data goes.
That matters in a world of compressed exploit cycles because it does not depend on knowing the exploit in advance. When a trusted script starts behaving differently, when a dependency swaps in new code after deploy, or when a payload begins exfiltrating form data, the change is visible at runtime even if the underlying vulnerability is brand new. Pre-release scanning tells you about the code you shipped. cside tells you what is actually running right now.
Start with client-side security for full runtime script monitoring, or Privacy Watch to see exactly what third-party scripts collect and send.
Further reading on cside
- AppsFlyer Web SDK supply-chain compromise
- The biggest Magecart attacks in history (so far)
- Web supply chain attack through trojanized jQuery
- How compromised third-party scripts can prompt-inject AI agents
- Best practices for securing third-party scripts
As of 2026-06-03. Chrome zero-day counts and the GTIG findings reflect reporting available at that date.
About the author
Simon Wijckmans is the founder and CEO of cside. He writes about client-side security, browser-layer threats, third-party scripts, and the standards work needed to make the web safer.
