There is one number that describes what is happening in offensive security better than any amount of talk about the “AI era.” It is the time from vulnerability disclosure to first mass exploitation. A few years ago that number was measured in hundreds of days. In 2026 it is closer to ten hours, and in individual cases it is minutes. A meaningful share of bugs get hit before a patch even ships.
We spend a lot of our time on breach investigations at AgentOffense, and we see this shift up close. So instead of another abstract “AI is changing everything” think-piece, here is exactly where the defender’s time went, and what to do about it before someone else’s pipeline of models decides for you.
Where the defender’s head start went
The old attack lifecycle was long and predictable. A vulnerability gets published in a popular plugin, and the attacker still has real work ahead: understand the bug, write a scanner that walks sites and fingerprints the vulnerable version, tune the payload, get past whatever WAF is in the way. Every one of those steps cost time, and the sum of those delays was the defender’s head start. An admin could read the bulletin, pull the patch, and update before the scanning wave reached them.
Now every one of those steps has collapsed to nearly zero. A model writes a scanner tailored to one specific bug in minutes. The same model helps it route around filters wherever it stalls. Lists of vulnerable targets across the entire internet get compiled automatically through device search engines. What used to take a person and days now runs in parallel, around the clock, across a thousand threads at once.
Here is how that plays out, stage by stage.
| Attack stage | Before | Now |
|---|---|---|
| Understanding the bug, writing the exploit | days, needed a specialist skill | hours or minutes, the model writes and debugs it |
| Finding vulnerable targets | manual scanning, custom tooling | automatic, via device search engines |
| Getting past WAFs and filters | often a dead stop, scanner finds nothing | the model adapts the request and gets through |
| Scale | dozens of targets, sequentially | thousands of targets, in parallel |
| Defender’s patch window | days | hours, sometimes minutes |
One thing worth saying up front: there is no new magic here. The bugs being exploited are exactly the same class of bugs as five years ago. What changed is not the substance of the attacks, it is their speed and reach, and that is precisely what knocks the legs out from under the old “learned about the hole, patched it calmly next week” model.
The case with the numbers spelled out: PaperCut
The clearest illustration landed in late August, and we broke that campaign down in detail here. The short version: someone chained OpenAI Codex and DeepSeek models with the Netlas device search engine and a standard offensive toolkit, and pointed the whole pipeline at PaperCut, the print-management platform. The target was a fresh pair of bugs — an authentication bypass (CVE-2026-81578, CVSS 8.8) and an unsafe dynamic class-loading flaw (CVE-2026-82078, CVSS 9.4) — that chain into unauthenticated remote code execution.
What follows is the arithmetic that makes the case worth revisiting. According to GreyNoise, the pipeline breached at least 440 servers across 395 organisations in 48 countries within a few hours.
| Campaign metric | Value |
|---|---|
| Start to first code execution | under 4 hours |
| Time to first domain admin | 6 hours |
| 11 organisations breached back-to-back | 26 seconds |
| Full domain takeover at a US school | 7 minutes |
| Servers compromised | 440 |
| Organisations hit, across countries | 395 in 48 |
| Share from the education sector | roughly half |
Read that school line again. Seven minutes from initial access to full domain-admin rights. That is not a record set for its own sake, it is the new normal you need to get used to. Schools and universities took the brunt of it for a mundane reason: PaperCut tends to face the internet there, patch cycles are slow, and there is rarely a dedicated security team. For a spray-and-pray campaign hitting everyone at once, that is the ideal target — lots of identical, poorly locked-down, internet-facing installs.
Our take. There was no novel zero-day nobody in the world knew about here, and no exotic technology. It was ordinary bugs and ordinary tooling. The one thing that changed was operator throughput: a single person got the firepower that used to require an entire team.
Speed isn’t always about AI: the Marimo case
It is worth resisting the comfortable “AI did it” mantra here, and a recent Sysdig write-up, which we covered in full, quietly dismantles it. That case is worth revisiting for balance.
CVE-2026-39987 is a bug in Marimo, the interactive Python-notebook platform popular with data scientists. The cause is embarrassingly simple: the platform runs several WebSocket connections, and every one of them enforces an auth check, except one. The terminal endpoint, for whatever reason, did not check anything. Anyone who opened a connection to it got a command shell with the process’s own privileges. No password required.
The attacker, once inside, reached a remote SSH bastion in eight seconds: pulled AWS keys from two places at once (the process environment and the app’s Redis instance), used one of those keys to lift a private SSH key out of AWS Secrets Manager, and logged in to the host that runs the whole cloud estate. Eight seconds, one command. That is the number that made headlines.
Here is the honest part. Behind those eight seconds sit four hours. That is how long the person had already spent, in earlier sessions, writing and debugging their own tooling. By the time of the attack they had eight ready-made scripts, and all that was left was to press go. Over a nine-hour session they typed more than 850 commands by hand and used not a single public off-the-shelf hacking tool. And, notably, no AI at all.
How did the investigators tell a human from an agent? Sysdig had planted a trap in advance: one of the files carried a hidden instruction ordering any language model that read it to print a specific marker. An agent reading that file would have obediently given itself away. The human opened that exact file twice and never printed the marker once.
The lesson from Marimo is not “relax, AI has nothing to do with it,” it is the opposite. Eight seconds is execution stacked on top of hours of preparation. That is how strong attackers have always worked: build and rehearse the playbook in advance, then just hit run in the field. AI does not invent that speed. It hands it to people who previously lacked the skill to build the playbook themselves. For a defender, the conclusion is identical either way: you cannot assume you have time to react. A swarm of agents can be fast, and so can one well-prepared human operator.
The flip side: the economics of breach moved too
Speed is only half the story. The other half is that AI collapsed the barrier to entry and rewrote the economics of attack, and that shows up most clearly in our own investigations.
Running a mass campaign used to take more than an exploit. It needed management infrastructure too: a panel that harvests logins and passwords from breached sites, drops spam or malicious code, keeps a tally of victims. Someone had to write or buy that admin panel, and that cost time, money, and skill. The barrier to entry was real.
That barrier is gone now. In our investigations we increasingly find attacker panels that were generated end to end by a model. And here is the telling part: the attackers themselves barely look at their own code’s security. The model produced something that worked, and they shipped it as-is. As a result, we routinely find hardcoded logins and passwords, keys, and hidden paths sitting on attacker infrastructure — exactly the sins we have spent years lecturing ordinary developers about, now flourishing in the attackers’ own tools.
That sloppiness, incidentally, sometimes works in the victims’ favour. Hardcoded access and hidden paths left in a panel can be used to pull a list of the hundreds of breached sites that panel manages, and warn the owners. Often that is the first time people learn they were breached at all. To be clear: this is not about hacking back into attacker infrastructure, which is illegal. It is about what is readable in files the attackers themselves left exposed.
Anthropic’s own report on how their models get used in attacks, which we broke down separately, documents the same collapse in barriers to entry. Between December 2025 and August 2026 they saw Claude used not as an advisor but as an operator: running reconnaissance, writing and debugging exploits, exfiltrating data, rewriting malware until it stopped tripping antivirus. One group ran a “build fleet” of 13 agents operating on a schedule with no human in the loop. Another built a firmware-vulnerability pipeline that produced more than a dozen zero-day candidates in a month. The report’s headline finding is uncomfortable: sophisticated attacks no longer require sophisticated attackers. The gap between a well-funded state actor and a lone operator in a basement has nearly closed. Hence things that were unthinkable a year ago: a SaaS provider breached with access to 200+ downstream customers in 34 hours, a doxxing platform built by one person. The side effect for defenders: attribution by “signature” has become unreliable, since a solo actor now hits with the reach of a group.
What this means in practice
If you boil all of this down to one idea: it is not so much the methods that changed as the speeds. The old tempo we got comfortable working at no longer protects anyone. Here is what follows from that.
- Measure your reaction window in hours, not days. A once-a-year audit stopped being protection some time ago. If a hole starts getting exploited on the day it is disclosed, your perimeter needs continuous checking, not a calendar slot. That is a job for regular external penetration testing, not a once-a-year box-tick.
- Get anything that does not belong on the internet off the internet. PaperCut, notebooks like Marimo and Jupyter, admin panels almost never need to face outward. A VPN or even just an allow-list closes off half the stories in this piece. What is actually exposed on your perimeter is exactly what an external network penetration test will show you, honestly.
- Get your secrets under control. Long-lived keys sitting in environment variables and an open Redis instance are a ready-made chain from “one hole” to “attacker is already in your cloud.” Short-lived tokens expire faster than anyone can put them to use; a cloud configuration review is what finds the excess keys and permissions lying around your environment.
- Have a real incident-response plan and real logs on hand. In an attack where domain admin takes seven minutes, the entire post-mortem is built on logs. No logs, nothing to investigate, which means no way to know what was actually taken. An assumed-breach assessment is exactly what tests whether that response actually works before you need it to.
- Your own AI agents are a separate front. If you are running autonomous agents with real permissions and network access, you are already on the other side of the fence too. One prompt injection or one misconfiguration, and an “innocent” agent does something you will be held accountable for. Guardrails, logging, and live human oversight need to exist before an agent goes live, not after — which is exactly what AI agent penetration testing and a runtime firewall like Airlock are built for.
Bottom line
The world of breach is changing fast, and not for the better yet. AI gave attackers something they never had for free before: smart scanners that route around defences, and cheap management panels assembled in minutes. Defence, meanwhile, is roughly where it was. Our own investigations point to one uncomfortable conclusion: you need to react an order of magnitude faster than is customary, sometimes within the same hour a vulnerability goes public. Attacker sloppiness occasionally works in defenders’ favour and lets us warn victims in time, but you cannot build a strategy on someone else’s carelessness.
If your services face the internet, start with an honest question: how many hours would it actually take you to close a hole once it is announced? If the answer is “a couple of days, probably,” you have a problem, because the attacker’s entire cycle now runs in hours. The way to turn that from a guess into a fact is a penetration test or a full red team engagement. A separate piece on how LLMs are starting to break the applications themselves, not just the infrastructure around them, is coming next.