PaperCut's Two-Patch Week: What CVE-2026-82078 and CVE-2026-81578 Mean for MSSPs

The Second Patch Nobody Wanted to Ship

On August 27, 2026, PaperCut issued an urgent security bulletin for two zero-day vulnerabilities in PaperCut NG/MF, tracked as CVE-2026-82078 and CVE-2026-81578, both under active exploitation before a fix existed. The vendor shipped an emergency patch. Then, within roughly 48 hours, it shipped a second one, because attackers found a way around the first fix. That is not a routine patch cycle. That is a vendor discovering, in real time, that its own remediation had a hole in it.

If you manage PaperCut instances for clients, or if a client runs PaperCut and you found out about this from a Slack message instead of your own tooling, this is the post for you.

Why One Patch Wasn't Enough

The two CVEs chain together. Attackers combined them to achieve pre-authentication remote code execution against PaperCut's Application Server, no credentials required, no user interaction needed. That is about as bad as a vulnerability chain gets: it turns an internet-reachable print management server into a foothold with zero friction. The first emergency patch closed the initial access path. It did not fully close the chain. Within two days, PaperCut confirmed the fix could be bypassed and released a second patch to actually close the door.

Here is the part worth sitting with: every organization that patched fast and considered the incident closed after release one had a false sense of resolution for the entire gap between patch one and patch two. Patch compliance dashboards went green. The exposure did not.

Who's Exposed

PaperCut NG/MF sits in an enormous number of environments, especially in education, healthcare, government, and any mid-market or enterprise org with a managed print fleet, which is most of them. It is the kind of software nobody thinks about until it is the reason someone is inside the network. If a client has a print management server with an internet-facing Application Server component, or even one reachable from a segment that isn't as isolated as everyone assumes, they are in scope regardless of industry.

What "Patch and Close the Ticket" Misses

The standard MSSP playbook for a CVE like this is: identify affected assets, apply vendor patch, verify, close ticket. That playbook assumes the vendor's first patch is the last word. PaperCut's own release cadence just demonstrated why that assumption is dangerous. A patch ticket closed on day one told the client they were safe on day one and day two, while attackers were actively working the bypass.

This is the actual lesson from this incident, and it has nothing to do with PaperCut specifically. Vulnerability management tells you what should be fixed. It does not tell you whether the fix held, or whether someone got in during the window it didn't. That second question only gets answered by something watching the system continuously, not something that checked a box once and moved on.

The IOCs a SOC Should Actually Be Watching

For this specific chain, the indicators worth building detection logic around sit in three places:

• pc-app.exe anomalies. Unexpected child processes, unusual command-line arguments, or the Application Server process behaving in ways that don't match normal print-job handling.
• Truncated server.log entries. Logs that cut off mid-write or reset unexpectedly are a known artifact of processes being interrupted or manipulated, and they are exactly what an exploitation attempt or a cleanup step can leave behind.
• JDBC error strings appearing in server logs. PaperCut's Application Server talks to its backend database over JDBC. Exploitation attempts hitting the application layer in unintended ways tend to throw database errors that have no business showing up during normal print job processing.

None of these three things, on its own, proves compromise. Together, on a PaperCut host, in the current threat window, they are worth a page-out, not a ticket in tomorrow's queue.

Containment Over Alerting

Here is where the vendor's patch history becomes an operational problem instead of a headline. A patch ticket tells you what should have been fixed. It does not tell you whether the bypass was used against a specific client's server in the hours before patch two landed, and it does not isolate anything by itself.

This is the posture Vijilan's Global SOC runs on incidents like this: continuous monitoring of PaperCut Application Server logs and the network traffic around them, correlated against the specific IOC pattern, not a generic "unusual login" rule. When that pattern lights up, the response isn't a ticket queued for business hours. It's isolation of the exposed Application Server the moment it's flagged, cutting off lateral movement before someone confirms it's real, because by the time confirmation finishes, the window has usually already been used.

That is the difference between an alerting posture and a containment posture. Alerting tells someone something happened. Containment stops it from becoming something worse while the investigation catches up. For a vulnerability chain that beat its own vendor's first fix, containment is the control that actually matters, because the patch ticket alone was demonstrably not enough this time.

What Partners Should Do This Week

• Confirm every PaperCut NG/MF instance is on the second emergency patch, not just the first. Check version numbers, don't trust a closed ticket from last week.
• Verify no Application Server is internet-facing unless there is a documented, current business reason for it.
• Confirm logging on PaperCut hosts is intact and centralized somewhere it can't be quietly truncated without someone noticing.
• Build or request detection coverage for the three IOC patterns above, specifically, not as a subset of generic EDR noise.
• Have an isolation runbook ready for print infrastructure. Most incident response plans treat print servers as an afterthought. This week is a good argument against that.

For partners running client environments without the bandwidth to stand up this kind of continuous, PaperCut-specific watch themselves, this is exactly the gap white-labeled ThreatRespond™ Managed XDR from Vijilan is built to close, monitoring and containment delivered under your brand, with your client relationship intact. We never compete with our partners for their clients.

Questions about fit or scope belong on a call, not in a pricing table. Reach out through /msp, and for anything cost-related, /pricing has the current answer.

The Bottom Line

PaperCut needed two emergency patches in 48 hours to close one exploitation chain. That is not a knock on PaperCut, patching under active exploitation pressure is genuinely hard. It is a reminder that in a world where vendors ship fixes fast and still miss the bypass, the organizations that stay safe are the ones with something watching the server in between releases, not just the ones with the fastest patch cadence.

Frequently asked questions

What are CVE-2026-82078 and CVE-2026-81578?

They are two chained vulnerabilities in PaperCut NG/MF that, combined, allow pre-authentication remote code execution against the PaperCut Application Server. PaperCut disclosed both as actively exploited zero-days in an urgent security bulletin on August 27, 2026.

Why did PaperCut need a second emergency patch?

The first emergency patch closed the initial access path in the chain, but within roughly 48 hours PaperCut confirmed the fix could be bypassed and released a second patch to fully close the vulnerability.

Is patching alone enough to be safe from this chain?

Patching is necessary but not sufficient here. Organizations that applied only the first patch had a false sense of resolution during the window before the bypass was fixed. Continuous monitoring for the specific indicators tied to this chain is what closes that gap.

What should an MSSP watch for on PaperCut servers right now?

Anomalous behavior from the pc-app.exe process, truncated or interrupted server.log entries, and unexpected JDBC error strings appearing in server logs are the three indicators most tied to exploitation of this chain.