PaperCut’s Zero-Days Were Already Being Exploited — Then Attackers Broke the Fix
- The Mess: Attackers are chaining two PaperCut NG/MF zero-days — CVE-2026-81578 and CVE-2026-82078 — to reach unauthenticated remote code execution. Researchers then found ways around the first emergency fix, forcing PaperCut to release a second patch.
- The Damage: An internet-facing PaperCut server can be taken from an unauthenticated state to arbitrary Java code execution with the privileges of the PaperCut service.
- The Fix: Install PaperCut Emergency Patch Release 2 immediately for v24, v25 or v26, and investigate exposed servers for compromise and remote-access tooling.
PaperCut had a zero-day.
Then it had two.
Then the first emergency fix got bypassed.
That’s a bad week for a print server.
Attackers are actively exploiting two vulnerabilities in PaperCut NG and PaperCut MF, chaining them into a pre-authentication RCE attack against exposed servers. PaperCut says it has confirmed customer incidents, while researchers have observed exploitation in the wild.
And the story got worse when researchers found ways around the original emergency patch.
Two Bugs, One Shell
The first vulnerability is CVE-2026-81578, an authentication bypass rated CVSS 8.8.
It affects the PaperCut web management interface and can allow unauthenticated remote requests to reach administrative functionality before access validation is completed.
That gives the attacker something extremely valuable:
configuration control without logging in.
The second flaw is CVE-2026-82078, rated CVSS 9.4.
This one involves unsafe dynamic class loading in PaperCut’s database connection utilities.
When an attacker can manipulate the relevant configuration, PaperCut can load an attacker-selected Java class already available to the application.
That’s where configuration manipulation turns into code execution.
The Attack Chain Is the Problem
Individually, the vulnerabilities are bad.
Together, they’re worse.
The chain looks roughly like this:
unauthenticated request → configuration change → malicious class loading → Java code execution
No valid PaperCut credentials are required.
Huntress demonstrated a working exploit chain that could deliver a Derby archive over SMB and trigger code execution with the privileges of the PaperCut Application Server.
That’s not a theoretical attack.
It’s a server takeover path.
The First Patch Didn’t Hold
PaperCut released an emergency patch after learning that attackers were exploiting the vulnerability.
Then researchers at watchTowr found multiple ways around the initial fix.
During that investigation, an additional authentication bypass was also identified.
PaperCut responded with Emergency Patch Release 2, adding further hardening and extending the emergency remediation to version 24 as well.
This is the part administrators should not ignore.
Installing the first emergency patch isn’t enough.
PaperCut explicitly recommends replacing it with Release 2.
Attackers Were Already Inside
Huntress observed exploitation attempts beginning on August 26 and identified attacks against at least two customers.
PaperCut subsequently reported that threat actors targeting internet-facing Application Servers were installing legitimate remote-access software on compromised systems.
That matters because attackers don’t necessarily need to deploy noisy malware after gaining RCE.
A legitimate remote-access application can provide persistence while looking considerably less suspicious.
The exploit gets them in.
The remote-access tool helps them stay.
Why Print Servers Matter
A print management server doesn’t sound like a high-value target.
It can be.
PaperCut servers often sit inside corporate networks and interact with:
- Windows systems
- user accounts
- print infrastructure
- databases
- file shares
- domain environments
Once an attacker gets code execution on the server, the next objective doesn’t have to be printing.
The server becomes a foothold.
From there:
recon → credential theft → lateral movement → domain compromise
is a much more interesting attack chain.
Internet Exposure Makes It Worse
Security researchers estimate that roughly 1,000 PaperCut instances are exposed to the Internet.
That creates an obvious target list for attackers scanning for vulnerable deployments.
An attacker doesn’t need to know the organization first.
They can find the server.
Fingerprint PaperCut.
Attempt the exploit.
Then determine what the compromised machine can reach.
Internet-facing infrastructure turns a local software bug into an automated hunting opportunity.
This Is Now an Incident-Response Problem
PaperCut isn’t telling customers merely to patch.
Its advisory includes indicators of compromise, and the company has confirmed customer incidents.
Administrators should therefore ask two questions:
“Did we patch?”
and:
“Was the server already compromised?”
Check for unexpected remote-access software.
Review newly created files.
Inspect outbound connections.
Look for suspicious Java processes and unusual PaperCut configuration changes.
If the server was exposed while vulnerable, assume compromise is possible until proven otherwise.
The Fix
PaperCut’s current emergency guidance is clear:
install Emergency Patch Release 2.
It applies to affected PaperCut NG/MF versions 24, 25 and 26 and includes additional hardening beyond the original emergency release.
Don’t install the original emergency patch and call it finished.
Use Release 2.
Then investigate the server.
Bugstoday Opinion
This is exactly why we keep an eye on chained vulnerabilities instead of obsessing over CVSS scores.
An 8.8 bug isn’t necessarily an RCE.
A 9.4 bug isn’t necessarily remotely exploitable.
Put the two together and suddenly an unauthenticated attacker gets a shell.
Then the first patch gets bypassed.
Then the vendor ships another emergency fix.
And meanwhile, attackers are already installing remote-access software on compromised servers.
That’s not a routine vulnerability.
That’s an active incident.
Bugstoday verdict: if your PaperCut server was exposed to the Internet, don’t treat this as “another patch Tuesday.” Patch with Emergency Release 2, check for the first signs of compromise, and assume the attackers may already have visited.
Today’s Bugs. Tomorrow’s Breaches.
