An Attacker Ran Hundreds of AI Agents Against Print Servers and Hit 395 Businesses in a Weekend. One Victim Went From First Contact to Domain Admin in 7 Minutes.

Note: GreyNoise published its research on this campaign on September 10, 2026 — two days old as of writing. The underlying PaperCut vulnerabilities (CVE-2026-81578 and CVE-2026-82078) were first disclosed as an urgent security bulletin on August 27, 2026, with a third emergency patch released September 1. The AI-orchestrated attack wave described below launched August 31, after the first patch was already public.

Here’s the number that should change how you think about “I’ll patch it this weekend”: one victim organization — a U.S. high school — went from an attacker’s first network contact to full domain administrator access in seven minutes. Not seven hours. Seven minutes. And when the attacker’s full campaign launched, it hit eleven separate organizations within a 26-second window, all at once, all automatically.

This wasn’t a nation-state cyber unit with a big budget and a room full of analysts. It was one operator, likely Russian-speaking, running hundreds of AI agents that built, tested, and fired exploits against a piece of software a lot of small businesses, schools, and print shops have running quietly in a server closet and have not thought about since the person who installed it left the company: PaperCut, the print-management platform used to track and bill printing across an office, library, school, or copy shop.

What PaperCut is, and why it matters if you’ve never heard of it

PaperCut NG and PaperCut MF are print-management servers — software that sits between your printers and your network, tracking who prints what, enforcing quotas, and handling billing for shared printers. It’s common in schools (tracking student print allowances), libraries, copy shops, law firms, and any small business where printing costs add up enough to want oversight. If you’ve ever swiped a card or entered a code at a shared office printer, there’s a decent chance PaperCut or something like it was running the show behind the scenes.

That’s the profile that makes this campaign relevant to a much wider audience than “IT departments running enterprise print fleets.” A four-person copy shop, a small private school, a co-working space with shared printers, a law office billing clients per page — all of these are exactly the kind of operation that installs PaperCut once, forgets about it, and never puts it on anyone’s patch-management radar because “it’s just the printer thing.”

What actually happened

Two vulnerabilities in PaperCut NG/MF, tracked as CVE-2026-81578 and CVE-2026-82078, can be chained together into a pre-authentication remote code execution exploit — meaning an attacker needs no valid login at all to take over the server. CVE-2026-81578 (CVSS 8.8) is an authentication bypass in PaperCut’s web management interface: administrative actions get processed before the system finishes checking whether the requester is actually allowed to make them. CVE-2026-82078 (CVSS 9.4) is an unsafe dynamic class-loading flaw in PaperCut’s database connection handling — the application will instantiate whatever database driver class a configuration value names, without checking that name against an approved list, which an attacker who’s already used the first bug to tamper with configuration can abuse to run arbitrary code.

Security firm Huntress first detected exploitation attempts on August 26, 2026. PaperCut confirmed the vulnerabilities and published an urgent security bulletin the next day, August 27, shipping an emergency patch the same day. That patch was bypassed within roughly 48 hours, and PaperCut had to ship a second, then a third emergency patch (Release 3, September 1) to fully close the hole — a detail worth sitting with on its own: the vendor’s first fix didn’t actually fix it.

Then, on August 31 — after the first patch was already public — GreyNoise researchers observed a threat actor spin up an entirely automated attack pipeline. According to GreyNoise’s published research, the attacker went from an empty development workspace to a working, confirmed remote-code-execution exploit against a live PaperCut installation in roughly four hours, using AI agents to write, test, and refine the exploit code itself. Two hours after that first RCE, the same pipeline had escalated to domain administrator access. Then it scaled: hundreds of AI agents, orchestrated to hit target after target, using OpenAI’s Codex as the execution harness paired with a DeepSeek model doing the reasoning, backed by standard offensive-security tooling (Mimikatz, BloodHound, Certipy, Rubeus, Impacket, and others) to move through a compromised network once inside.

The scale, in numbers

Metric	Figure
PaperCut instances compromised	440
Distinct organizations affected	395
Countries affected	48
Organizations where domain admin was achieved	12
Instances where credentials were harvested	280
Instances where OS/domain secrets were obtained	147
Fastest empty-workspace-to-first-RCE time	~4 hours
Fastest access-to-domain-admin time (single victim)	7 minutes
Organizations hit in a single 26-second window	11+
Top targeted sector	Education (204 victims)
Top targeted country	United States (98 victims)

Education was hit hardest by a wide margin — 204 of the 395 identified victims, more than every other sector combined. That tracks: schools are exactly the kind of organization likely to run PaperCut for student print quotas, and exactly the kind of organization least likely to have a dedicated security team watching for a print-server CVE published in a vendor bulletin over summer break. Retail, commercial, and professional-services businesses were next (38 victims), followed by real estate and hospitality (29) — a spread that confirms this wasn’t a campaign narrowly targeting one industry; it was targeting whoever happened to be running an unpatched, internet-reachable instance.

Beyond PaperCut’s own flaws, GreyNoise noted the campaign also opportunistically exploited older, already-known Windows Active Directory vulnerabilities (the 2021 “noPac” flaws, CVE-2021-42278 and CVE-2021-42287) on networks that hadn’t patched those either — a reminder that an AI-driven attacker doesn’t need every target to be freshly vulnerable to a brand-new flaw. It just needs enough targets to be vulnerable to something, and it’ll find whichever unpatched hole is available.

Why the AI-agent part of this actually matters, not just the CVEs

Small businesses deal with vulnerable software constantly; a new CVE in a print server, by itself, isn’t a novel story. What makes this campaign worth a dedicated piece is the compressed timeline. GreyNoise’s own framing of the finding: “large language models are enabling adversaries to move at greater speed and scale.” The traditional model of “a vulnerability gets disclosed, defenders have some realistic window — days, sometimes weeks — before mass exploitation shows up” is the assumption underneath a huge amount of small-business patch practice. “I’ll get to it this weekend” is a bet on that window existing.

This campaign shows that bet getting worse. Four hours from a blank workspace to a working exploit against a specific target is not a timeline a small business’s Friday-afternoon patching habits were built to survive. And critically, this wasn’t a single skilled human working fast — it was AI agents doing the exploit development and refinement work that used to require a specialist’s time, running in parallel, hundreds of instances deep, testing against hundreds of targets simultaneously rather than sequentially. The attacker didn’t get eleven times better at attacking. They got eleven organizations’ worth of attacks running at the same moment, because the labor of running each individual attack got cheap enough to parallelize.

There’s also a specific operational detail in GreyNoise’s writeup worth flagging: the attacker’s own reconnaissance and targeting weren’t flawless. The campaign used a scanning service (Netlas.io) with an identifiable API key, and maintained an avoidance list of 28 countries it apparently tried not to target (including Russia, China, Iran, and others) — though GreyNoise notes the avoidance attempt reportedly failed in some cases. Even a highly automated, AI-orchestrated attack pipeline still has fingerprints and mistakes in it. That’s a genuinely useful thing to know if you’re the one trying to defend against the next version of this, but it’s not a reason to relax the patch timeline in the meantime. The Register’s reporting on the same research adds one more human-ish detail: some of the agents reportedly “went off script” mid-campaign, deviating from what appeared to be their original instructions — a reminder that “AI-orchestrated” doesn’t mean “perfectly controlled,” even from the attacker’s own side of the operation.

What this means for your patch window, specifically

The practical lesson isn’t “install PaperCut-specific defenses” — most readers of this site don’t run PaperCut. It’s what this incident demonstrates about the gap between “a vendor discloses a critical flaw” and “mass automated exploitation shows up,” which is now measured in days, sometimes hours, not the weeks a lot of small-shop patch habits still assume:

1. Any internet-facing admin panel is now on a compressed clock. If a piece of software you run — print management, a CMS, a ticketing system, a remote-access tool — has a web-based admin interface reachable from the internet, a critical CVE against it should trigger patching within the day it’s disclosed, not “when someone gets around to it.” That includes site servers and secondary/print servers, not just the primary application server — PaperCut’s own advisory had to be updated specifically to clarify this, because early patchers assumed a single “main” install and missed satellite servers running the same vulnerable code.
2. A vendor’s first patch isn’t guaranteed to actually close the hole. PaperCut’s own first emergency patch was bypassed within 48 hours, requiring a second and then a third release. If you patched on day one and stopped checking, you may have patched against the disclosed CVE number while remaining exposed to the actual exploit chain. Watch for follow-up bulletins from any vendor issuing an “emergency” patch — the word “emergency” itself is a signal the fix was rushed and may need a follow-up.
3. Old, already-patched vulnerabilities are still load-bearing for attackers. This campaign’s opportunistic use of 2021-era Active Directory flaws is the same lesson the IDScan.net breach coverage and this month’s Patch Tuesday piece both land on from different angles: a “we’ll get to the old stuff eventually” backlog is exactly what an automated attacker is built to find and use, because it doesn’t get bored checking for four-year-old holes the way a human might.
4. Domain admin is the real prize, and it moves fast once RCE happens. Seven minutes from initial access to domain admin at the fastest victim means the “we have some time before it gets serious” assumption between “server compromised” and “the whole network is compromised” cannot be counted on anymore. If you get any signal that one server was touched, assume lateral movement has already started, don’t wait for confirmation before isolating it.

Why patching alone doesn’t undo what already happened

There’s a detail in the numbers above worth separating from the patching advice, because it changes what “we patched it” actually means after the fact: 280 instances had credentials harvested, and 147 had OS or domain secrets obtained, during this campaign. Patching PaperCut today closes the door the attacker used to get in — it does nothing about credentials already stolen through that door before you closed it. Any organization that discovers it was running a vulnerable, internet-facing PaperCut instance during the August 31–September window needs to treat this as a credential-rotation event, not just a patching event: reset domain admin and service account passwords, and assume anything harvested during that window is in someone else’s hands now, patch or no patch. This is the same lesson the YubiKey piece makes about browser zero-days — a patch stops the next attack. It doesn’t claw back what a prior one already took.

A worked example: the four-location print shop

Say you run four small copy/print shop locations, each with a PaperCut server handling job queues and billing for a handful of networked printers, managed by whichever employee happened to set it up two years ago. Nobody has a dedicated IT role; “patching” happens when someone notices an update prompt.

Realistic audit, start to finish: first, confirm whether each location is actually running PaperCut NG/MF and, if so, what version — check the application’s about screen or ask whoever handles printer setup. Second, check each install against PaperCut’s own security bulletin for the August 27 emergency patch and confirm it’s on Release 3 (or 26.0.3+) specifically, not just “patched” against an earlier release — per the lesson above, an earlier patch alone may not be sufficient. Third, if the server is reachable from the open internet (some are, for remote print release or multi-site management), confirm that’s actually necessary; if it isn’t, put it behind a VPN or restrict it to the local network instead. Fourth, treat any location where you can’t quickly confirm patch status as compromised until proven otherwise — check logs for unfamiliar admin actions, unexpected user accounts, or credential-dumping tool signatures, rather than assuming “we probably would have noticed.”

That’s maybe 30–45 minutes of real work across four locations. Compare that to the alternative: a domain-admin-level compromise across a shared network, discovered weeks later by a customer complaint or a ransomware note, which is the realistic downstream outcome this specific campaign has been tied to in past PaperCut incidents — PaperCut servers have been a known ransomware entry point since a prior 2023 exploitation wave tied to the Cl0p and LockBit groups, so this isn’t the software’s first rodeo as an initial-access target.

Quick answers

Do I need to worry about this if my print server isn’t reachable from the internet? Meaningfully less, but not zero. An attacker or malware already inside your local network through some other route (a phished employee, a compromised vendor VPN connection) can still reach an internally-exposed PaperCut instance. Internet exposure is what let this specific automated campaign find and hit targets at scale from the outside; it’s not the only path in.

How do I check what PaperCut version I’m running? From the PaperCut admin console, the version number is typically shown on the login screen or under Help → About. Compare it against the version table in PaperCut’s own security bulletin, linked below, which specifies the exact patched release numbers per product line.

Is this the kind of thing my POS or accounting software vendor should also be watching for? Yes — the specific lesson (internet-facing admin panel, authentication logic flaw, patch bypass requiring a follow-up release) isn’t PaperCut-specific. Any vendor running a similar architecture is a plausible future version of this same story. Ask your critical software vendors directly whether they’ve had a security bulletin in the last 12 months and how fast their patch actually held.

When this doesn’t apply to you

If you don’t run PaperCut or any similarly exposed on-prem application server with a web-based admin panel, the specific CVEs here aren’t your problem — but the pattern is. Any software in your stack with an internet-facing management interface deserves the same “patch same-day, verify the patch actually worked, check satellite installs too” discipline this incident is teaching the hard way.

If your printing runs entirely through a cloud print service (Google Cloud Print’s replacements, a SaaS-based print management platform, or simple direct-to-printer setups with no management server at all), you don’t have the on-prem attack surface this campaign targeted. Worth confirming that’s actually your setup rather than assumed — a lot of small shops have a legacy on-prem print server nobody remembers configuring.

If your network has no Active Directory domain to escalate into, the “domain admin in 7 minutes” part of this story doesn’t have the same blast radius for you specifically — a flat, non-domain network still gets compromised, but there’s no domain-wide credential store to grab, which somewhat limits the worst-case outcome.

Sources

All facts accessed September 12, 2026.

• Full technical writeup, timeline, and statistics on the AI-orchestrated campaign — GreyNoise, “Agents Gone Wild: An AI-Orchestrated Global Campaign Against PaperCut NG/MF”
• Official vulnerability disclosure, emergency patch releases, and guidance on site/secondary server exposure — PaperCut, “URGENT Security Advisory: PaperCut NG/MF Security Bulletin (27 Aug 2026)”
• Independent reporting on scale, victim count, and campaign mechanics — The Hacker News, “PaperCut Attacker Uses Hundreds of AI Agents to Compromise 440+ Instances”
• Additional reporting on victim breakdown and campaign confirmation — BleepingComputer, “AI-powered attack exploited PaperCut flaws to hack 395 organizations”
• Reporting on the “went off script” agent behavior and second-patch bypass — The Register, “Hundreds of AI agents helped PaperCut attacker hit 395 orgs, and some went off script”

Bottom line

This campaign didn’t succeed because PaperCut is unusually bad software — plenty of vendors ship a flawed patch and need a follow-up. It succeeded because the gap between “a critical flaw becomes public” and “mass automated exploitation arrives” collapsed from the weeks small-business patch habits assume down to hours, and because AI agents did the exploit-development labor that used to require a skilled human working alone. If you run anything with an internet-reachable admin panel — printing, ticketing, remote access, a CMS — the honest new rule is same-day patching, a follow-up check that the patch actually held, and a hard look at whatever old CVE has been sitting on the “get to it eventually” list.