PaperCut RCE Vulnerability Actively Exploited

A newly disclosed PaperCut RCE vulnerability is already being exploited against PaperCut NG and PaperCut MF print management servers worldwide. PaperCut confirmed active attacks on August 27, 2026, shipped an emergency patch within hours, then replaced it with a hardened second patch the next morning after researchers found the first fix incomplete. Every organization running an internet-reachable PaperCut Application Server should treat this as urgent.

What Happened

This PaperCut RCE vulnerability is actually two chained flaws. CVE-2026-81578 is an access-control bug in the web management interface: a specially crafted, unauthenticated request tricks PaperCut’s authorization check into approving an action tied to a different page than the one it verified, letting an outside attacker change server configuration values. CVE-2026-82078 then abuses PaperCut’s database-connection utilities, which load Java classes dynamically without properly validating what they load — combined with the first flaw, this gives an unauthenticated attacker arbitrary Java code execution inside the PaperCut Application Server process.

PaperCut says all versions of PaperCut NG and PaperCut MF are potentially affected. Emergency patches are available now for the v25 and v26 branches; a fix for v24 is still in progress. Security firm Huntress independently reproduced the full chain and triggered a SYSTEM-level process spawned under the PaperCut server. In live incidents already observed, attackers ran basic reconnaissance (whoami & ver, and separately whoami & ver & tasklist) and dropped a self-deleting Java payload that also scrubs the server’s own log file — one confirmed intrusion lasted under two minutes.

PaperCut has a documented history here. In 2023, a different PaperCut RCE (CVE-2023-27350) became a widely used initial-access vector: Clop and LockBit ransomware affiliates, and later Iranian state-linked groups and the Bl00dy gang, all exploited it — not to steal anything stored in PaperCut, but simply to get a foothold inside the rest of the network.

Why It Matters

PaperCut NG and MF sit in the print-management stack of schools, universities, public administration bodies and Mittelstand offices across the DACH region — infrastructure that is rarely the first thing an IT team thinks to expose-check, and is exactly the kind of “boring, ubiquitous, sometimes accidentally internet-facing” software this workspace keeps seeing exploited. Given the 2023 precedent, the realistic risk here is not limited to print data: a compromised PaperCut server is a plausible stepping stone into the wider network, credential stores, and — for NIS2-regulated entities — a reportable incident if it leads anywhere further.

What You Should Do Now

1. Apply PaperCut’s Emergency Patch Release 2 immediately for the v25 or v26 branch. If you are on v24, PaperCut’s fix is still in progress — isolate the server in the meantime.
2. Check whether your PaperCut Application Server is reachable from the public internet. If it is, restrict access to trusted internal IP addresses via firewall rules or network access controls right now, even if you have already patched.
3. If no immediate mitigation is possible, take the Application Server off the internet entirely until Release 2 is confirmed installed.
4. Hunt for indicators of compromise: unexplained activity from pc-app.exe, missing or truncated server.log files, and the log strings ERROR No suitable driver found for jdbc:no:x or ERROR DatabaseUtils - Database error looking up cardID: VALUES CAST. PaperCut itself warns that an absence of these indicators does not confirm a server is clean.

Preserve the full server/logs directory, current configuration, and relevant firewall/proxy logs before you patch or restart — if the server was exposed, this evidence changes the moment you touch it.

DIESEC Perspective

The gap between PaperCut’s first emergency patch and the hardened Release 2 less than 24 hours later is itself a data point worth internalizing: a vendor’s first fix under pressure is not automatically the complete fix. This is a pattern we see regularly in Mittelstand environments — a patch gets applied and the ticket gets closed, but nobody circles back to confirm the vendor’s own follow-up hardening ever landed.

Not sure whether your print infrastructure or other public-facing management interfaces have this kind of exposure gap? Contact DIESEC for a rapid external exposure and patch-verification review.

Sources: BleepingComputer | Huntress
Published: 2026-08-31 | Category: Vulnerabilities & Patches | ~4 min read