Your emergency patch was not the finish line.

The dangerous sentence in patch management is "we already handled that."

PaperCut released an emergency fix for an actively exploited flaw. Researchers found ways around it, so the company released a second emergency patch later the same day. If your team installed the first one and closed the ticket, the vulnerable server may still be sitting there with a green check beside its name.

That is not a reason to distrust patches. It is a reason to stop treating patching as proof that nothing happened.

What happened

On August 27, PaperCut warned that attackers were exploiting vulnerabilities in PaperCut NG and PaperCut MF, the company's print-management servers. The company had confirmed customer incidents and told anyone with an internet-accessible Application Server to restrict its web interfaces to trusted IP addresses immediately.

The technical picture came into focus the next day. CVE-2026-81578, rated 8.8, lets an unauthenticated request change certain server configuration. CVE-2026-82078, rated 9.4, lets someone who controls that configuration load arbitrary Java code. Huntress reproduced the two flaws as a chain that produces remote code execution before login.

PaperCut shipped an initial emergency patch, then issued Release 2 after additional analysis with Huntress and watchTowr. BleepingComputer reported that researchers found multiple bypasses in the first fix. PaperCut's instruction is unambiguous: install Release 2 even if you already installed the original emergency patch.

The second patch covers major versions 24, 25, and 26 on Windows, Linux, and macOS. Customers on version 23 or earlier need to upgrade rather than wait for a backport. Site Servers and secondary print servers need the patched version too, not just the primary Application Server.

"Patched" describes the software you are running now. It says nothing about what ran before the patch.

The attacker may have arrived first

Huntress found exploitation in two customer environments. In one, the visible activity lasted less than two minutes. Attackers used the PaperCut process to run discovery commands and delivered a Java class capable of executing operating-system commands. That class then deleted its output and the main PaperCut log.

PaperCut's updated advisory now describes a longer observed sequence. It begins with whoami, process and domain discovery, then moves to downloading remote-access software. Within roughly 22 minutes, the attacker installed a SimpleHelp service running as LocalSystem; a few minutes later, it downloaded AnyDesk.

This is why "we patched it" is an incomplete incident response. A patch closes an exploit path. It does not remove a remote-access agent, restore a deleted log, revoke credentials the server could read, or make a compromised host trustworthy again.

The absence of the published indicators does not settle the question either. Both PaperCut and Huntress warn that the exploit cleans up some of its own files. Clean-looking logs can be evidence of cleanup, not evidence of safety.

Why this matters beyond one print server

Emergency fixes are produced under pressure and with incomplete information. PaperCut says Release 2 is not a normal product release, and it has received reports of problems with SAML and some external card-number database lookups after installation. That operational friction is real.

So is active exploitation.

The answer is not to wait for a prettier installer. It is to separate containment, remediation, and recovery. Restrict access now. Apply the current fix. Investigate the period when the server was exposed. Those are three different jobs, and skipping one does not make the others more complete.

What I'd actually do today

1. Find the server before you debate the patch. Inventory every PaperCut NG and MF Application Server, Site Server, and secondary print server. Record the exact version, operating system, owner, and whether any web interface has been reachable from the internet.
2. Cut off public access. Restrict the Application Server web interfaces to trusted internal addresses, a VPN, or another controlled administrative path. PaperCut recommends doing this even after patching. A print-management console does not need a public front door.
3. Preserve evidence before restarting. Copy the full server/logs directory with file metadata. Preserve endpoint process trees, firewall and DNS logs, recent services and scheduled tasks, and reverse-proxy records. An upgrade or reboot can erase the timeline you need.
4. Install Emergency Patch Release 2 everywhere it applies. Do not assume the first patch is sufficient. Update versions 24 through 26 using PaperCut's current bulletin and verify the vendor-provided checksum. Upgrade version 23 and older to a supported release.
5. Hunt for execution, not just a CVE scanner result. Look for command shells spawned by pc-app.exe, missing or truncated server.log files, unexpected five-character .class, .cmd, or .out files, the vendor's published database error strings, a service named Remote Access Service, and unplanned AnyDesk installations.
6. Treat a positive signal as a compromise. PaperCut recommends securing backups, wiping and rebuilding the Application Server, and restoring a clean backup from before the suspicious activity. Also rotate any credentials the server could access and review where those credentials were used.
7. Keep the ticket open until the facts stop changing. The vendor was still updating indicators and operational guidance through August 31. Subscribe to its security notifications, assign one owner, and record which patch release was installed—not merely that the system was "patched."

The bottom line

A patch can close a door. It cannot tell you who walked through it yesterday.