1 SEP 2026 — PaperCut has issued a second emergency patch for two actively exploited flaws after watchTowr found multiple ways around the first one, plus an additional authentication vulnerability. An emergency patch written under exploitation pressure is the patch most likely to be incomplete. Applying it on day one and closing the ticket is the failure this incident illustrates.
The two flaws
CVE-2026-81578 is an authentication bypass rated 8.8. Unauthenticated remote requests aimed at administrative functions trigger backend actions before access validation completes, so the check runs after the work has already been done.
CVE-2026-82078 is rated 9.4 and is an unsafe dynamic class-loading flaw. The application loads database driver classes by configurable name without validating those names against an allowlist, which permits arbitrary Java bytecode execution.
PaperCut NG and MF versions 24, 25 and 26 are affected, with Emergency Patch Release 2 available for all three on Windows, Linux and macOS. Version 23 and earlier will not receive patches and should be upgraded.
Why the first patch was bypassable
watchTowr reproduced both flaws and then found multiple bypasses of the fixes, along with a further authentication vulnerability that had not been reported. That sequence — reproduce, then probe the fix — is the standard method and it works far more often than vendors would like.
The reason is structural. A vendor under active exploitation optimises for shipping something today, which usually means blocking the specific request pattern the attacker used rather than correcting the underlying logic. A filter on an input is quick to write and quick to test; restructuring an authentication path so validation completes before any action is taken is neither.
An incomplete fix of that kind stops the published proof of concept and does not stop the vulnerability class. Anyone who reads the patch diff learns exactly which shape was blocked, which is a useful hint about what was not.
The class-loading bug is a design pattern, not a slip
Loading a class by a name taken from configuration is a common convenience in Java applications, and it is how database drivers have been selected for decades. It becomes a remote code execution primitive the moment that name can be influenced by anyone untrusted.
The fix is an allowlist, which is unglamorous and complete: enumerate the driver classes the product supports and refuse everything else. There is no scenario in which a printing product needs to load an arbitrary class named at runtime.
This pattern is worth looking for beyond PaperCut. Any application that takes a class name, a handler name, a deserialisation target or a plugin path from configuration has the same shape, and the question worth asking of your own estate is whether those values are validated against a fixed list or merely trusted because they live in a config file.
Print servers keep appearing on this list
Print management is not obviously high-risk software, and it keeps producing incidents of this severity for reasons that have nothing to do with printing.
A print server sits in the middle of the network by design, because it has to be reachable from every workstation. It usually runs with high privilege, because installing drivers and managing spools requires it. It authenticates against the directory, because print quotas are per-user. And it is frequently exposed externally, because remote and mobile printing were requested.
That combination describes an ideal pivot point rather than a peripheral service, and it is why an unauthenticated code execution flaw here is worth more to an attacker than the same flaw in something more obviously sensitive. The equivalent question for any estate is which other quiet, privileged, universally reachable services are being patched on the schedule given to a printing utility.
What the exploitation actually looked like
Huntress observed exploitation in two customer environments. The attackers used hex-encoded Java class files for reconnaissance, and no malware deployment or persistence mechanism was confirmed.
Do not read reconnaissance without persistence as reassurance. An operator might be deciding whether an environment is worth returning to, or confirming a technique before using it at scale. It is also what remains visible when the persistence step happened somewhere the investigation did not look.
The practical implication is that "we were exploited but nothing was dropped" is not a conclusion available on day one. It is an absence of evidence produced by a specific set of checks, and it should be recorded with the scope of those checks attached.
What to do this week
Apply Emergency Patch Release 2 rather than the 27 August release, and confirm which one is actually installed rather than which one was downloaded. On version 23 or earlier, the upgrade is the patch and there is no alternative.
Then treat the print server as compromised until checked, because a system with an unauthenticated code execution path that was exploited in the wild does not get the benefit of the doubt. Look at scheduled tasks and services created since 25 August, unexpected files in the application directory, and outbound connections from the print server to anything that is not a printer or a directory service.
The structural fix is network placement. A print management server has no reason to accept connections from outside the network, and it is routinely exposed because a remote-printing feature was easier to enable than to route. We reported that these flaws were being exploited before a CVE was assigned, which is the same lesson in a different order: the identifier arrives after the attack, and a server reachable from the internet is exposed for the entire interval in between.
View author profile → · Editorial policy
