Eleven organisations were compromised in the first twenty-six seconds, and nobody picked them. That is the part of GreyNoise's PaperCut report worth arguing about: not that agents made an intrusion fast, which we already knew, but that choosing four hundred victims now costs an operator what choosing one used to cost. Every security programme that survives on being uninteresting has been spending a discount that just went to zero.
At a glance
One operator, one campaign, reported by a single vendor's telemetry.
| Reported figure | Value | What it tells you |
|---|---|---|
| Campaign start | 31 August 2026 | Roughly five days after the first observed exploitation of the chain |
| Compromised instances / organisations | 440+ servers, 395 orgs, 48 countries | Breadth, not depth, was the design |
| First twenty-six seconds | 11 organisations | Target list and exploit were ready before launch |
| Worst-hit sector | Education — 204 victims | The sector with the least response capacity, first |
What actually happened
PaperCut NG/MF is print-management software. The chain is two flaws: CVE-2026-81578, an authentication bypass in the web management interface where administrative actions are processed before access validation completes, rated 8.8 on CVSS v4.0; and CVE-2026-82078, unsafe dynamic Java class loading in the database connection utilities, rated 9.4. Chained, they give arbitrary Java execution in the application server's context with no credentials. Huntress reported the first known exploitation on 26 August 2026 and reproduced the full pre-authentication chain.
GreyNoise published its analysis on 9 September. It describes an operation that began on 31 August from a single source address, run by a likely Russian-speaking actor, using hundreds of AI agents to develop, test and refine exploits for both CVEs and then to work the results. The agents were, per the report, driven by OpenAI's Codex harness with a DeepSeek model behind it — reporting differs slightly on the exact model split — alongside ordinary publicly available offensive tooling. The first remote code execution landed less than four hours after the operator started from an empty workspace. At one US high school, the report says, domain administrator was reached seven minutes after initial access.
Follow-on actions were run per victim rather than sampled: credentials harvested from 280 organisations, operating-system or domain secrets from 147, administrator privileges at 12.
Two separate claims live in this story and only one of them is new. "An agent can execute known tradecraft quickly" is the claim the ten-hour intrusion and the Aurora chat logs already established. "An operator can run the same tradecraft against every exposed instance on the internet at once, and then do the per-victim follow-up too" is the new one, and it is an economics claim rather than a capability claim.
The obscurity discount, and who was paying with it
Nobody writes it in the risk register, but almost every organisation under a few thousand employees has been running on a real and load-bearing assumption: that a competent attacker has to decide we are worth the hours. That assumption was never about our controls. It was about the attacker's scarcest input, which was attention. Prioritisation on the offensive side has done more for mid-market security than most of what the mid-market bought.
What an agent fleet changes is exactly that input. Scanning was already cheap. Exploit adaptation across differing versions and configurations was not, and neither was the unglamorous part after initial access — reading the environment, finding the credential store, working out what this particular network is. That work is the reason campaigns used to be shaped like a funnel that narrowed: an operator picked the victims worth their evening. In this campaign it did not narrow much. 395 organisations were compromised and 280 had credentials harvested; the operator did not have to choose.
So the education number is not a curiosity, it is the prediction. 204 of 395 victims were schools and universities — institutions that run internet-facing appliance software, have small or no security teams, and were previously protected by the fact that nobody could be bothered. When selection stops costing anything, the population that gets hit is simply the population that is exposed, and exposure correlates with under-resourcing rather than against it.
The control that failed was the patch window, and it is priced in hours
Trace the timeline as a defender and the decision points are uncomfortable. Exploitation in the wild on 26 August. A mass campaign five days later. Eleven organisations inside half a minute of its start. Nothing in that sequence has room for a monthly patch cycle, a change advisory board, or a print server whose owner left in 2023.
The instinct is to reach for detection — and detection here is unusually hard in one specific way. The agents were not running novel techniques; the report is explicit that the offensive tooling was commodity. There is no AI-shaped signature to alert on, because the AI was in the operator's workflow, not on the wire. This is the same conclusion the wiki's attacker-operated agents page reaches from the other direction: you are not going to detect the model.
What is left is boring and measurable:
- Know what of yours answers on the internet. Not the application inventory — the listening-port inventory, including the appliance nobody calls software. A print server, a file-transfer box, a badge system. The campaign's whole target list was an internet scan, so your exposure is defined the same way the attacker defines it.
- Set the patch SLA against the mass-exploitation window, not the disclosure date. For internet-facing, pre-auth-RCE-class bugs in appliance software, that window is now measured in days, and the first hours of it are automated. A 30-day SLA for this class is not a slow control; it is an absent one.
- Pre-authorise the containment action. The only response that fits inside a 26-second launch is one that does not wait for a person to approve it: take the appliance off the internet, revoke the service account, isolate the host. Decide who may do that, and to what, before the incident — the argument kill switches makes about your own agents applies exactly as well to your own infrastructure.
- Assume credential harvest on any compromise of this class. 280 of 395. Rotation scope is the question to have answered in advance, because the blast radius of a harvested secret is determined by choices you made months earlier.
If you take one action from this report, make it the asset question, and answer it today rather than architecting: which internet-facing systems do we run that are maintained by a vendor, patched by hand, and owned by nobody currently employed here? That list is short, it is knowable in an afternoon, and it is the list this campaign was written against.
What this does and does not say about agents
It is worth being precise, because "AI-powered attack" headlines have a way of proving whatever the reader already believed.
The campaign does not show a model discovering a novel vulnerability; the CVEs were public and already exploited. It does not show autonomous attack; there is an operator, with an objective, iterating. And the single-vendor telemetry means the victim counts are a floor for what that vendor could see, not a census.
What it does show is an operator using agents for the part of offence that has always been the bottleneck — the per-target adaptation work — and getting a fleet out of it. That is the same capability profile the defensive side has been demoing for two years, pointed the other way, and it arrives with the same property: the scarce resource stops being skill and becomes the ability to supervise volume. On the attacker's side, nobody has to supervise anything. On yours, everything still routes to a person, which is why the response clock keeps turning out to be the number that matters.
FAQ
Did AI agents find these vulnerabilities?
No. Both CVEs were publicly disclosed and already being exploited before the campaign started; Huntress reported exploitation on 26 August and GreyNoise dates the campaign to 31 August. The agents developed, tested and refined working exploits for known flaws, then ran them at scale.
Is 395 organisations the real total?
It is the number one threat-intelligence vendor observed. Counts like this are floors, not censuses — they reflect what that vendor's sensors saw, and other victims may be unobserved or unreported.
Why was education hit hardest?
Almost certainly because it was exposed rather than because it was chosen. Schools and universities run a lot of internet-facing operational software with small security teams and long patch cycles. When target selection costs nothing, the victim distribution tracks exposure, and exposure is highest where capacity is lowest.
Would an EDR or an AI-detection product have stopped this?
Endpoint detection may well catch the post-exploitation steps, and should. An "AI detection" layer would not have helped, because nothing on the wire was model-generated in a detectable way — the tooling was commodity and the model was in the operator's workflow. The controls that bite here are exposure reduction, patch velocity and pre-authorised containment.
What is the single number to fix?
Time from a pre-auth RCE disclosure in internet-facing software to that software being patched or taken off the internet. If you do not know your current value, that is the finding.
Further reading
On this wiki:
- Attacker-operated agents — why detecting the model is the wrong control, and what replaces it.
- Vulnerability management for agent platforms — patch velocity as an engineering property.
- Kill switches — pre-authorised stop actions, and who is allowed to pull them.
- Incident response for agents — the response clock, staffed.
- Ten hours, fifty techniques, no zero-days — the depth-first version of the same arithmetic.