PaperCut ships second emergency patch for actively exploited pre-auth RCE chain in MF and NG

PaperCut pushed a second emergency release after the first fix fell short

PaperCut has shipped a second emergency patch for its MF and NG print management servers to shut down a pre-authentication remote code execution chain that attackers are already exploiting. According to BleepingComputer, whose August 28 report is summarised in a technical write-up on dev.to, the first emergency fix failed to close every authentication bypass vector, which is why the vendor issued Release 2 covering product versions 24, 25 and 26.

The chain pairs two vulnerabilities. CVE-2026-81578 is an authentication bypass that lets an unauthenticated attacker invoke backend management operations and alter database-related settings before any login check is applied. CVE-2026-82078 is a dynamic class-loading flaw: database driver class names are not validated against a whitelist, so Java bytecode that an attacker has placed on the server's classpath can be loaded and run.

How the attack works

The write-up describes a short, mechanical attack flow. An unauthenticated attacker reaches the management interface, uses the bypass to call management operations, changes database-related settings, and specifies an unapproved driver class name. The server loads the attacker's deployed Java class, and on Windows the pc-app.exe process executes commands with SYSTEM privileges. The attacker then removes output files and the server.log to cover their tracks. No user interaction is required at any stage.

Huntress confirmed real-world exploitation

The managed security provider Huntress confirmed successful exploitation at two customer sites, according to the report. Its investigators observed SYSTEM-privilege command execution originating from pc-app.exe, the deployment of Java classes named Udydn.class and Moo97.class, and the deletion of server.log. The write-up rates the overall issue as critical in severity.

Indicators administrators should check

The analysis lists several detection signals:

• A process tree in which pc-app.exe spawns whoami, ver, tasklist or cmd.exe.
• Unknown .class, .cmd and .out files under the server/lib directory, together with a missing server.log.
• derby.log entries containing jdbc:derby:memory:pwn or the error "No suitable driver found".
• Outbound connections to unfamiliar destinations after suspected exploitation.
• For cloud-hosted deployments, WAF, load balancer and audit logs.

Beyond applying Release 2, the recommended mitigations are to move any installation on a version older than v23 to a current release line, restrict the management interface to trusted IP ranges or a VPN, and block unknown classes from being placed in server/lib or executed by pc-app.exe. Where compromise is confirmed, the server should be isolated and related credentials and sessions revoked.

What successful exploitation yields

An attacker who completes the chain gains code execution with the same authority as SYSTEM on the PaperCut server. From that position they can read configuration and connection data, steal credentials, stage additional payloads and establish a foothold for lateral movement inside the network. Because the activity blends in with normal operation and logs are deleted, monitoring the user interface alone is unlikely to catch it; the write-up stresses correlating HTTP, application, process and network logs across timestamps rather than relying on individual indicators.

Open questions remain, the analysis notes: the total number of affected organisations, the scope of any data access, what further payloads were deployed, and whether all of the bypass vectors left in the initial release were actually used in the wild.

Why it matters

Print management consoles are frequently exposed to the internet and treated as low-priority infrastructure, which makes a no-interaction, pre-auth RCE chain with SYSTEM-level reach an attractive target for opportunistic attackers. The incident also carries a broader lesson for incident response: an emergency patch is not proof of containment. Organisations that applied the first release remain vulnerable and must move to Release 2, and because successful intruders delete server.log, patching alone is not enough. A proper hunt through process trees, server/lib and derby.log is needed to rule out an existing compromise.