PaperCut's Second Emergency Patch: Why the First Fix Didn't Hold

PaperCut is having the kind of week vendors dread. After shipping an emergency patch for a chained pair of zero-days in its NG and MF print management servers, the company had to go back and issue a second emergency patch once researchers demonstrated the first fix could be bypassed entirely. That detail — a patch broken almost as fast as it shipped — is what elevates this from routine vulnerability disclosure to a genuine incident defenders need to be tracking today.

The technical chain

Two CVEs are doing the damage here. CVE-2026-81578, rated 8.8, is an improper access control flaw that lets unauthenticated requests reach administrative functions that should never be reachable without a session. On its own that's bad enough, but it becomes a launching pad for CVE-2026-82078, rated 9.4, an unsafe dynamic class-loading vulnerability that permits arbitrary Java bytecode execution once configuration parameters are altered. Chained together, the two flaws give an attacker pre-authentication remote code execution on internet-facing print servers — no credentials, no user interaction, just a network path to the service.

That's a particularly ugly combination for print management infrastructure, which is frequently deployed at the network edge to handle print jobs from external or hybrid workforces and just as frequently forgotten about in patch cycles. Print servers aren't glamorous, but they typically sit with elevated privileges to interact with domain resources, making them a useful pivot point once compromised.

Active exploitation, not theoretical risk

This isn't a disclosure-then-wait scenario. Huntress has already observed active exploitation in customer environments, and the behavior they're seeing is telling: attackers performing reconnaissance rather than immediately detonating ransomware. That pattern is consistent with access brokering — establishing a foothold, mapping the environment, and quietly confirming value before handing off or selling access to a ransomware affiliate. Organizations that assume they have time because they haven't seen encryption yet are misreading the threat; the reconnaissance phase is often the only warning window before a more damaging follow-on attack.

The patch-bypass problem

The fact that PaperCut's initial remediation could be circumvented is the detail worth sitting with. It means organizations that patched promptly after the first advisory and considered themselves covered were, for a period, still exposed to essentially the same exploitation path. This is a recurring theme with complex, chained vulnerabilities — a fix that closes one access-control gap can leave adjacent logic, like the dynamic class-loading behavior tied to configuration parameters, still reachable through a slightly different request pattern. Defenders relying on patch-and-forget need to re-verify against the second emergency patch specifically, not assume the earlier update remains sufficient.

The legacy version problem

Perhaps the most sobering figure in the reporting is that roughly 47% of tracked PaperCut installations are running versions old enough that they are ineligible for the current patch. That's not a small tail of stragglers — it's nearly half the exposed population that has no vendor-supplied fix available at all. For those environments, the only real mitigations are isolating the servers from the internet, restricting access to trusted networks or VPN, and monitoring aggressively for the reconnaissance behaviors Huntress has already documented.

What defenders should do now

Teams running PaperCut NG or MF should confirm they are on the latest emergency patch, not just the first one issued, and validate that confirmation against vendor guidance rather than assuming prior remediation holds. Internet-facing PaperCut instances should be reassessed for whether they need to be exposed externally at all — if remote printing access can be tunneled through a VPN instead, that removes the pre-auth attack surface entirely. Given the reconnaissance-then-ransomware pattern already observed, logging and alerting on unusual administrative-function access or unexpected class-loading activity on these servers should be treated as high priority, not background noise. And for the large population stuck on unsupported versions, upgrading off legacy PaperCut deployments needs to move from a someday item to a near-term project — the exposure isn't going away on its own.