PaperCut CVE-2026-82078: a Pre-Auth RCE Turns the Print Server Into a Ransomware Doorway

PaperCut runs the print queue for universities, hospitals, law firms and government agencies — quiet, trusted, and almost never on a security team's threat model. On 27 August 2026 that changed. PaperCut disclosed two chained zero-days, CVE-2026-82078 (CVSS 9.4) and CVE-2026-81578 (CVSS 8.8), that together let an unauthenticated attacker run arbitrary Java code on the PaperCut Application Server. Huntress observed exploitation in the wild from 26 August — a day before the advisory — and then watched the first emergency patch get bypassed. If that sequence feels familiar, it should: this is the same product, and nearly the same failure mode, that Cl0p and Bl00dy rode into networks in 2023.

What the PaperCut CVE-2026-82078 chain actually does

Neither bug is exotic. That is the point — they are old classes re-imported into a trusted appliance.

CVE-2026-81578 is an improper access-control flaw in the web management interface. According to Rapid7's analysis, it abuses Apache Tapestry's "complex direct" request format: the framework renders a public page while quietly dispatching an administrative component, so the access-validation check runs after the privileged action has already fired. That gives an unauthenticated remote caller write access to the ConfigEditor.

CVE-2026-82078 is where the config write becomes code execution. PaperCut loads database driver classes by name from configuration without checking them against an allowlist. Having reached ConfigEditor through the first bug, the attacker repoints four user-lookup settings at a Derby JDBC driver with an H2-style JDBC URL carrying an inline INIT statement. A UserList search then triggers a JavaScript-backed database trigger that loads and runs attacker-supplied Java bytecode. The jdbc:h2:...;INIT=... gadget is a decade-old Java RCE primitive; here it is reachable pre-authentication.

CVE	CVSS	Class	Role in the chain
CVE-2026-81578	8.8	Improper access control	Unauthenticated write to ConfigEditor via Tapestry "complex direct"
CVE-2026-82078	9.4	Unsafe dynamic class loading	Config write → Derby/H2 INIT trigger → arbitrary Java bytecode

Chained, the two produce unauthenticated RCE as the account running pc-app.exe — on Windows deployments, frequently SYSTEM.

Why an exposed PaperCut server is a ransomware doorway

This is not a hypothetical. In 2023, CVE-2023-27350 — another PaperCut authentication bypass leading to RCE — became a mass initial-access vector. As BleepingComputer reported, Microsoft tied that exploitation to the Cl0p ransomware operation, the Bl00dy gang hit the education sector with it, and Iranian state-aligned actors joined in. Three of PaperCut's prior flaws are already on the CISA KEV catalog, two of them exploited in ransomware.

A print server is an ideal beachhead for exactly the reasons that keep it off the threat model:

• It runs as a high-privilege service account, often SYSTEM, on a Windows host joined to the domain.
• It is supposed to talk to every workstation and print device, so lateral fan-out from it looks like normal operation.
• It holds directory-lookup credentials and card/user data — useful for the next hop.
• Nobody watches it. EDR coverage on utility appliances is thin, and log retention is often days, not months.

The exposure math is not comforting. SecurityWeek, citing Shadowserver, put roughly 1,000 PaperCut instances directly on the internet, most in North America and Europe. Huntress separately noted that about 47% of the installations it tracks are on v23 or older — versions that never received these patches because they are out of support.

The PaperCut patch that wasn't

Here is the detail that turns this from "patch and move on" into a hunting exercise. PaperCut's first emergency patch shipped, and then watchTowr Labs found ways around it. PaperCut published Emergency Patch Release 2 on 28 August, and — per BleepingComputer — now tells every customer to install Release 2 even if they already applied the first patch.

That is the trap most write-ups skip:

"We patched on the 27th." "Which patch?" "The emergency one." "There were two. The first one was bypassable. And exploitation started on the 26th — before either of them. What did you do to check whether something got in during the window?"

A patch stops the next attacker. It does nothing about an implant already dropped through the H2 trigger. Given that first exploitation predates the advisory, "we patched" and "we are clean" are two different claims, and only one of them is checkable.

Remediation

Treat any internet-facing PaperCut NG/MF server as potentially touched between 26 August and the moment you applied Release 2. Work the list top to bottom.

1. Am I affected?

All NG and MF versions are in scope until Emergency Patch Release 2. Confirm your running version and exposure:

• Version: Help → About in the admin console, or check [install-path]/server/lib/pc-app.jar build metadata. Exploitation is confirmed on builds as recent as v24.1.5.71847 and v25.0.10.75465 (Huntress).
• Exposure: from outside your network, check whether TCP 9191 (HTTP) or 9192 (HTTPS) answers. Anything reachable from the internet is presumed hit.

2. Patch — the exact fixed target

Upgrade to Emergency Patch Release 2 on your major line — PaperCut NG/MF version 24, 25, or 26, Release 2 (Windows, Linux, macOS). Release 1 is not sufficient; it was bypassed. Versions 23 and earlier receive no fix and must be migrated to a supported line. This is verbatim from the PaperCut advisory and the Canadian Centre for Cyber Security bulletin AV26-858.

3. Can't patch this hour? Compensating controls

• Restrict the web interface to trusted IPs. PaperCut's own primary guidance: put a firewall ACL in front of ports 9191/9192 so only your print-management subnets and admin jumphosts can reach them. This blocks the unauthenticated entry path outright.
• Pull the Application Server off the public internet. There is no legitimate reason for the admin interface to face the world.
• Enforce egress filtering from the print-server host — it should not be initiating outbound sessions to arbitrary internet destinations.

4. Hunt for compromise (IOCs → ATT&CK)

The exploit leaves distinctive, checkable artifacts. From Huntress's incident data:

• Unexpected .class files in [install]/server/lib/ with random five-character names, e.g. Udydn.class, Moo97.class (names vary per incident). Legitimate PaperCut ships no such files.
• .cmd / .out files appearing under [install]/server/data/content/.
• server.log signatures: DB URL: jdbc:derby:memory:pwn, a boot entry like memory:...\server\data\internal\pwn, hex-encoded Java bytecode, or the error strings No suitable driver found for jdbc:no:x and DatabaseUtils - Database error looking up cardID: VALUES CAST. A truncated, missing, or freshly deleted server.log is itself an indicator (T1070.004).
• Process telemetry: pc-app.exe spawning a command shell, charmap.exe or other discovery utilities running as SYSTEM under pc-app.exe.
• Base64 recon commands in logs — d2hvYW1pICYgdmVy (whoami & ver) and d2hvYW1pICYgdmVyICYgdGFza2xpc3Q= (whoami & ver & tasklist), mapping to T1082/T1057.

ATT&CK path: T1190 (exploit public-facing app) → T1059 (command execution via the loaded class) → discovery (T1082, T1057) → T1070.004 (log deletion).

5. Eradicate + verify

Patching is step two of five, not the whole job:

1. Delete confirmed malicious .class and .cmd/.out artifacts, then rebuild rather than trust any server that shows implant signatures — a Java class loader that ran once can have seeded persistence you will not find by eye.
2. Rotate every credential the server could reach: the PaperCut admin password, the database connection account, the service account running pc-app.exe, and any directory-lookup / bind credentials stored in config.
3. Review domain authentication logs for the service account making lateral connections it never made before.
4. Only after Release 2 is applied and credentials are rotated, confirm the server is clean and no new implant reappears on restart.

Catching it on the wire when the print server turns

Every step above assumes you already know the server was hit. The uncomfortable case is the one where the log is truncated, the .class file self-deleted, and the patch went on cleanly — so the console says green while an operator sits inside with SYSTEM on a domain-joined host. That is precisely the gap Zero Hunt's AI Traffic Analysis was built for.

A print server has one of the most predictable traffic baselines in the estate: it ingests print jobs and talks to directory services on a handful of ports. The moment it starts doing something else — an outbound TLS session to a never-seen ASN, a beacon cadence, an SMB write burst fanning out to file shares, a sudden DNS-over-HTTPS spike — the behaviour diverges from ten months of learned normal. Zero Hunt's deep-learning model runs four inference heads (suspicious traffic, malware classification, attack-type identification, application fingerprinting) over live PCAP at 2.7+ Gbit/s on the appliance GPU, entirely on-prem. It flags the RCE callback and the ransomware staging as they happen — not in tomorrow morning's SIEM digest, and not dependent on a server.log the attacker already deleted. For the canonical PaperCut-to-ransomware kill chain, in-progress detection on the network is the layer that does not lie about being clean.

The complementary question — are we even exposed, and did the fix actually take? — is where the 10-agent generative pentest closes the loop. A change-triggered campaign fires when a new PaperCut server appears on the perimeter, and the swarm writes a per-target exploitation attempt against the actual host rather than replaying a signature. Because the first patch was bypassable, "validated not exploitable against Release 2" is a stronger statement than "we installed the update," and every attempt is ECDSA-signed at write time so the evidence stands up in an incident review or an insurance claim. Patch, then prove the patch — on a doorway this well-worn, the proof is the part that matters.