CVE-2026-82078: PaperCut's Pre-Auth RCE Chain

If you run PaperCut NG or MF and haven’t patched since August 28, you’re not done. PaperCut’s first emergency patch that day didn’t actually close the hole; researchers found a bypass within hours, and a second emergency release followed before the weekend. Two chained CVEs, tracked as CVE-2026-82078 (CVSS 9.4) and CVE-2026-81578 (CVSS 8.8), let an attacker with no account and no prior access run code on your print management server. CISA added both to its Known Exploited Vulnerabilities catalog on August 31, and reporting since then shows unpatched, already-compromised servers now being used for data theft.

What the two bugs actually do

PaperCut NG and MF sit in an unusual spot in a lot of networks: they’re print management software, which sounds low-stakes, but they typically hold live database credentials, run with elevated system privileges to talk to print queues across a building or campus, and are reachable from ordinary user VLANs because every desk needs to print. That combination is exactly what makes this chain dangerous.

CVE-2026-81578 is an authentication bypass in the web management interface. Under specific conditions, an unauthenticated request aimed at an administrative function triggers the backend action before the server finishes checking whether the requester is allowed to make it. In plain terms: the door is supposed to check your badge before it opens, and this bug lets the door open first and check the badge after, if it checks at all.

CVE-2026-82078 is the more severe of the two. PaperCut’s database connection utilities instantiate a database driver class based on a configurable driver name, and that name isn’t validated against a list of approved drivers before the server loads and runs it. If an attacker can influence that configuration value, which the authentication bypass hands them a path to do, they can point the server at a class of their choosing and get arbitrary Java bytecode executing under the security context of the PaperCut server process. That’s remote code execution, no credentials required, before authentication has meaningfully happened at all.

Chained together, the two bugs turn an anonymous network request into a shell on the PaperCut Application Server.

Why the first patch wasn’t the end of it

PaperCut published a security bulletin on August 27 and shipped its first emergency patch the next day, covering versions 25 and 26. That’s a fast turnaround for a vendor, and normally the story would end there. It didn’t: researchers at watchTowr and Huntress found ways to route around the initial fix within the same day, and PaperCut shipped a second emergency patch, Emergency Patch Release 2, before the week was out. That second release also extended coverage to version 24, which the first patch hadn’t touched.

The practical lesson isn’t a knock on PaperCut specifically; incomplete first patches on a fast-moving zero-day aren’t rare. It’s that “we patched last week” isn’t the same claim as “we’re on the version that’s actually safe.” If your change log shows you applied the August 28 update and stopped there, check the exact build number against the table below before you consider this closed.

Who’s affected, and what’s fixed

PaperCut line	Status	Fixed version
24.x	Affected (all releases before the fix)	24.1.10
25.x	Affected (all releases before the fix)	25.0.13
26.x	Affected (all releases before the fix)	26.0.5

Both NG and MF are in scope, self-hosted and on-prem deployments alike. PaperCut says the vulnerable code path touches every current release line, which is unusually broad; there’s no “you’re on an old enough version to be safe” carve-out here the way there sometimes is with a bug introduced in a specific release.

How to patch it

1. Update to 24.1.10, 25.0.13, or 26.0.5, matching your current major line. If you’re running anything earlier than that on the same line, this is the version to land on, not an intermediate one.
2. Confirm the build number, not just that an update ran. If your last patch predates the second emergency release, you applied a fix that researchers demonstrated a bypass for. Re-patch.
3. Check PaperCut’s published indicators of compromise against your logs, particularly around the disclosure window (roughly August 25 through 28), before you assume a pre-patch server was untouched.
4. Rotate credentials the PaperCut server held, especially any database connection strings, if you can’t rule out compromise during the exposure window. Code execution under the server’s process context means an attacker had access to whatever that process could reach, not just PaperCut’s own data.
5. Review network exposure. PaperCut Application Servers reachable from general user networks (which is common, since it’s how desktop clients submit print jobs) have a larger practical attack surface than ones restricted to admin subnets, even though the vulnerability itself doesn’t require special network positioning to exploit.

The broader pattern worth remembering

This is the second time this year an internal, unauthenticated-by-necessity interface (a password reset flow, an admin bootstrap check, a driver-loading utility) has turned into a full compromise path, and it won’t be the last. Any component that has to accept some requests before full authentication is complete, because that’s how account recovery or admin management works, deserves the kind of scrutiny that “it’s just an internal print server” doesn’t usually get. If your organization runs self-hosted infrastructure tools that fit that description and haven’t had a focused security review recently, that gap is worth closing before a CVE forces the conversation. We help teams audit exactly this class of exposure in self-hosted admin and management interfaces before it becomes an incident.

Patch to 24.1.10, 25.0.13, or 26.0.5 if you haven’t already confirmed the exact build, and don’t treat “we patched in August” as sufficient without checking which patch.