Two Minutes on the Print Server: The PaperCut Zero-Day Chain That Ends in SYSTEM

On 26 August 2026, somebody spent less than two minutes inside a PaperCut Application Server. They ran whoami & ver, base64-encoded, through a Java class file they had just dropped into server/lib/. Then they ran it again with tasklist appended. Then they deleted server.log and left.

Huntress caught it in two customer environments and published the teardown. PaperCut shipped an urgent advisory the next day, 27 August, with the first emergency patch out at 1:20 PM ET. A second patch followed on 28 August with extra hardening and, importantly, coverage for version 24. CISA added both CVEs to the Known Exploited Vulnerabilities catalog on 31 August.

Two minutes. That is the part I keep coming back to. Whoever this was did not stick around to loot the box. They confirmed they had SYSTEM, confirmed what was running, wiped the log that proved it, and disconnected. That is not smash-and-grab. That is somebody building an inventory.

The chain is two ordinary bugs that compose into something nasty

Neither CVE is exotic on its own. Together they are a clean pre-auth path to code execution.

CVE-2026-81578 is an improper access control flaw in the web management interface, rated CVSS 8.8 by runZero. The mechanism is a page-rendering bypass: a crafted request can name one page to be rendered in the response while a different page owns the component or action that actually executes. You get to invoke privileged actions without ever authenticating. In practice that means an unauthenticated attacker can change system configuration.

CVE-2026-82078 is the payoff, rated CVSS 9.4. It is an unsafe dynamic class loading flaw in PaperCut's database connection utilities. The application will load Java classes referenced through its JDBC configuration. Normally that is how you swap in a Postgres or SQL Server driver. If you can write the JDBC configuration and place a .class file where the loader looks, the application loads your bytecode instead of a database driver.

So the chain is: bypass auth, rewrite the database connection settings, make the app load your class, own the process.

The fingerprints Huntress documented are worth memorising because they are absurdly specific. Log lines reading DB URL: jdbc:derby:memory:pwn. Errors reading ERROR No suitable driver found for jdbc:no:x. Java class files with five-character random names, Udydn.class and Moo97.class, sitting in server/lib/ where no class file should ever appear after installation. Matching .cmd and .out files under server/data/content/. And pc-app.exe spawning a command shell, or in one observed case charmap.exe, which is the kind of parent-child pair that should light up any EDR console.

Here is the detail that makes this more than a print bug: on Windows, pc-app.exe runs as SYSTEM. Not as a service account with scoped rights. SYSTEM, on a server that is almost always domain-joined.

Why a print server is a better target than the CVSS score suggests

I have done enough internal assessments to know how print management servers get treated. They are owned by the facilities team or the IT ops generalist. They sit in a flat VLAN because printers are everywhere. They are excluded from the aggressive EDR policy because somebody once decided the Java process was causing spooler timeouts. Nobody has looked at the console since the last driver rollout.

And yet look at what actually lives on that box.

PaperCut synchronises users and groups from Active Directory or Entra ID. That sync runs over LDAP, and unless you are relying purely on the machine account, it runs with a bind credential stored in configuration. It holds database connection credentials, which on a mid-size deployment often point at a shared SQL Server instance rather than the embedded database. It holds the full org chart: usernames, email addresses, departments, office locations, group memberships, and which of those people have administrative rights inside PaperCut. If you are an attacker who just landed and needs to know who the finance team is and where they sit, a print management directory is a better first read than most HR systems.

Now the part that is not in anybody's advisory, and which I want to be precise about because it is my analysis rather than an observed technique.

PaperCut's own documentation makes a point of saying it never caches user passwords. Authentication is done by real-time interrogation of the directory at the moment somebody logs in. That is genuinely good design, and it is the right answer for a system that a whole workforce touches daily. But "never cached" is not "never seen." Every time an employee types their domain password into a PaperCut web login or a copier release screen, that password transits the Application Server process in plaintext on its way to the LDAP bind. It is in memory. It is inside the process you just got arbitrary Java bytecode execution inside.

An attacker who wanted domain credentials at volume would not need LSASS dumping or Kerberoasting on this box. They would need patience and a hook on the authentication path. Then they would wait for Monday morning, when a few thousand people walk up to a copier and prove who they are.

That is the shape of the risk here, and it is why I would rank this well above where the print-server-shaped mental model puts it. Compare it to the service account blind spot we mapped after the FortiGate intrusions: the same pattern, an unglamorous system holding directory credentials, invisible to the controls that watch user endpoints.

2023 was the rehearsal, and the attendance was terrible

PaperCut has been here before. CVE-2023-27350 was a CVSS 9.8 unauthenticated RCE, also landing SYSTEM, disclosed in March 2023 and publicly detailed that April. It got broadly exploited by everybody: Cl0p affiliates tracked as Lace Tempest, LockBit, and the Bl00dy ransomware gang.

The FBI's contribution to the joint CISA advisory is the number I find most instructive. Bl00dy hit victims across the Education Facilities Subsector, and education entities accounted for roughly 68% of exposed United States PaperCut servers. Schools and universities, running an internet-facing print server because students need to print from dorms, getting ransomed through the printing system.

Three years later, the exposure has not gone away. Shodan and ShadowServer both put over 1,000 PaperCut NG/MF instances reachable on the public internet on their default management ports. That is not a huge number in absolute terms. It is a huge number for a system that has no business being internet-facing at all.

The patch math is worse than the patch timeline

PaperCut moved fast. Advisory on 27 August, patch the same day, hardened patch on 28 August. By vendor standards that is a strong response, especially compared to the N-central patch bypass that Storm-1175 rode into MSP networks, where the original fix turned out to be incomplete.

The problem is who can actually apply it. Huntress reported that 47% of the roughly 2,500 PaperCut installations it tracks are running version 23 or older. At the time of publication there was no emergency patch for those. The remediation path is not "apply patch," it is "perform a major version upgrade of the system that prints everybody's payslips," which is a change-control conversation, a driver compatibility review, and a maintenance window.

So for roughly half of a real-world install base, the response to an actively exploited pre-auth RCE chain was: firewall it and hope. runZero's guidance reflects that reality, and adds a point defenders keep missing. Patch the site servers and secondary print servers as well, not only the primary Application Server. Those secondaries are the ones nobody inventoried.

This is the recurring gap. Detection cannot depend on the patch arriving, because for a large fraction of the estate the patch does not arrive for months.

Detecting an intruder who deletes the evidence

Go back to the intrusion sequence. The payload wrote its command output to a file, and then deleted server.log.

That is the whole problem with log-based detection on a compromised host, in one step. Your SIEM ingests what the host sends it. If the attacker owns the host as SYSTEM and truncates the log before your forwarder ships it, the intrusion did not happen as far as your console is concerned. A missing log file is itself a signal, but only if somebody is alerting on gaps in a print server's log volume, and almost nobody is. It is the same structural weakness we covered in the analysis of why deception survives EDR killers: controls that live on the box die with the box.

Deception inverts the dependency. A decoy does not need the compromised host to report anything. It needs the attacker to touch something, and the alert fires from somewhere the attacker does not control.

On a PaperCut server, that maps almost too neatly onto the attack. Consider what an intruder does in their first sixty seconds after landing: read the configuration to find the database, read the configuration to find the directory bind account, enumerate who the admins are. Every one of those is a read of a file you control.

Put a decoy JDBC connection string in the server configuration alongside the real one. Put a fake LDAP bind credential in the directory sync settings. Seed the PaperCut admin user list with a plausible service account that no human will ever authenticate as. None of those affect printing. None of them generate false positives, because there is no legitimate workflow that uses them. The only way anybody touches them is by reading configuration they have no business reading, and then trying the credential. When that credential gets used against your domain, you have an alert with a timestamp, a source IP, and zero ambiguity about whether it matters. That is the argument for honeytoken-based detection across the estate, and print infrastructure is close to the ideal placement: high value to an attacker, zero legitimate credential churn.

The second placement worth considering is the exposure itself. If over 1,000 PaperCut servers are internet-facing, attackers are scanning for them. A MineField decoy service presenting a PaperCut-shaped listener on the default management port gives you an early-warning tripwire on the exact scan that precedes this exploit chain. You find out you are on somebody's target list before they find the real server.

What I would do this week

Inventory first, and include the secondaries. Patch to Emergency Patch Release 2 on 24.x, 25.x or 26.x. If you are on 23 or older, accept that you are in the 47% and treat network isolation as the primary control rather than a stopgap. Take the management interface off the internet, permanently, regardless of version.

Then hunt for the IOCs, because the exploitation window opened before the advisory. Any .class file in server/lib/ you did not put there. Any jdbc:derby:memory: or jdbc:no: string in your configuration or logs. Gaps or truncation in server.log. pc-app.exe with child processes. Five-character filenames under server/data/content/.

And then ask the harder question, the one this incident is really about. Your print server authenticates every employee you have, runs as SYSTEM, holds directory credentials, and is monitored by nobody. How many more boxes like that do you own? The FortiBleed credential database made the same point from a different direction last week: the credentials attackers use are already sitting in infrastructure you stopped thinking about years ago. If you want to find out what an attacker sees when they land on one of those boxes, and get an alert the moment they read it, book a walkthrough with our team and we will show you where the decoys go.