PaperCut Zero-Day Exploitation Escalates to Data Theft, Third Emergency Patch Required

PaperCut Software published an urgent security advisory on August 27 confirming active exploitation of vulnerabilities in PaperCut NG and PaperCut MF, its print management software. The vendor assigned CVE-2026-81578 (an 8.8-severity authentication bypass in the web management interface) and CVE-2026-82078 (a 9.4-critical unsafe dynamic class-loading flaw in the database connection utilities) the next day. Both were added to CISA's Known Exploited Vulnerabilities catalog on August 31 based on confirmed active exploitation.

How the Exploit Chain Actually Works

The authentication bypass alone lets an attacker invoke privileged PaperCut components without valid credentials. Chained with the second flaw, an attacker can reconfigure an external database lookup — and when that lookup triggers, malicious SQL executes, resulting in full remote code execution. This is a textbook example of why a single high-severity bypass and a separate critical flaw, neither necessarily catastrophic in complete isolation, become a full remote-code-execution chain once combined.

From Reconnaissance to Active Data Theft

• Exploit activity has been observed since late August, with threat actors shifting from reconnaissance to hands-on-keyboard activity
• At least one actor has abused the authentication bypass to hijack PaperCut's external user-lookup functionality specifically for data theft
• Database tables are being dumped via Derby (PaperCut's embedded database), meaning this isn't just unauthorized access — it's active exfiltration
• Both CVEs' addition to CISA's KEV catalog is itself a signal: that list is reserved for vulnerabilities with confirmed, not just theoretical, active exploitation

The Detail Every PaperCut Admin Needs to Know

PaperCut released its first emergency patch on August 28 at 02:10 AEST for versions 25 and 26, followed by patches for version 24 later the same day — and then a second emergency patch after the first proved insufficient. Critically, organizations that applied only the first or second emergency patch are still not fully protected and need to apply the third patch immediately. Confirming exactly which patch version is actually running — not just that "a patch was applied" at some point — is the single most important action item here.

Why This Matters Beyond PaperCut Specifically

An emergency patch needing two follow-up revisions before it actually closes the hole is a real, current illustration of a broader problem: with more than 130 CVEs published daily and exploit windows collapsing to just days industry-wide, the assumption that "we patched it" is safe the moment a vendor ships a fix is increasingly unreliable. Verifying a patch actually closed the specific exploited vulnerability — not just that an update was installed — is worth building into incident response as a distinct, required step, not an assumption.