As reported by The Hacker News, attackers are actively chaining two newly patched PaperCut vulnerabilities — CVE-2026-82078 and CVE-2026-81578 — to achieve unauthenticated remote code execution on exposed PaperCut NG and MF instances. Huntress researchers observed early-stage reconnaissance activity, suggesting exploitation is already underway in the wild.
Vulnerability Summary
| CVE | CVSS | Severity | Description | Patch Available |
|---|---|---|---|---|
| CVE-2026-82078 | 9.4 | Critical | Unsafe dynamic class loading in database connection utilities — driver names not validated against allowlist | Yes — emergency patch released |
| CVE-2026-81578 | 8.8 | High | Improper access control in web management interface — unauthenticated requests can trigger backend actions before authorization completes | Yes — emergency patch released |
Affected Products
- PaperCut NG — unpatched versions
- PaperCut MF — unpatched versions
Active Exploitation Status
Confirmed in the wild. Huntress reports observed activity consistent with early-stage reconnaissance, including commands to enumerate user accounts and operating system details. PaperCut has released a second emergency patch with additional hardening beyond the original fix, indicating the initial remediation may have been insufficient.
Why This Matters
The attack chain is particularly concerning because it demonstrates a classic Time-of-Check-Time-of-Use (TOCTOU) pattern in the authorization layer. The access control flaw (CVE-2026-81578) allows an unauthenticated request to bypass permission checks by exploiting a mismatch between the rendered page and the component executing backend logic. Once that gate is open, the unsafe dynamic class loading vulnerability (CVE-2026-82078) provides the vehicle for arbitrary Java code execution within the application's trusted process context.
PaperCut is widely deployed across enterprise, education, and government environments — typically as a print management server that organizations instinctively treat as low-risk infrastructure. This perception mismatch is exactly what makes it dangerous. These servers often run with elevated privileges, integrate with Active Directory, and sit on internal networks with broad access. An attacker who gains RCE on a PaperCut server effectively has a foothold deep inside the trusted network perimeter.
The need for a second emergency patch with "additional hardening" is a red flag. When a vendor must re-patch the same vulnerability class within days, it suggests the original fix addressed the symptom but not the root architectural weakness — in this case, the decoupling of authorization checks from action execution.
Who Is at Risk
Immediate Actions
- Patch immediately — apply the latest PaperCut emergency patch (the second release, not just the first). Verify the build number against PaperCut's advisory.
- Isolate PaperCut servers — restrict network exposure. PaperCut management interfaces should never be internet-facing. Implement allowlisting at the network layer to limit access to print management ports.
- Hunt for compromise — review PaperCut application logs for unusual configuration changes, unexpected database driver modifications, or anomalous administrative API calls. Look for reconnaissance commands (whoami, hostname, systeminfo equivalents).
- Validate the class loading allowlist — after patching, confirm the new driver allowlist is enforced and that custom or unexpected driver entries cannot be injected.
- Audit exposed endpoints — map all PaperCut instances in your environment. Shadow IT deployments in departmental or campus settings are common and frequently unpatched.
Shield53 Recommendations
Beyond immediate patching, organizations should treat this incident as a signal to reassess how print management infrastructure is segmented and monitored:
- Network segmentation — Place PaperCut servers in a restricted VLAN with firewall rules limiting access to only necessary print queues and administrative workstations. The management interface should require VPN or jump host access.
- Privilege minimization — Run PaperCut services under a dedicated least-privilege account rather than SYSTEM or domain admin credentials. Review what directory integrations the service account has and constrain them.
- Continuous monitoring — Deploy EDR coverage on all PaperCut hosts. Configure detection rules for Java process spawning unexpected child processes, configuration file modifications outside maintenance windows, and outbound connections from the PaperCut service account.
- Vulnerability management discipline — Add PaperCut to your critical patch SLA. The historical pattern of PaperCut vulnerabilities being weaponized (this is not the first instance) demands it be treated as tier-one infrastructure, not a forgotten print server.
- Tabletop the scenario — If an attacker gained RCE on your PaperCut server today, what would they reach next? Map the lateral movement paths and prioritize closing them.
The combination of broad deployment, privileged integration, and now demonstrated active exploitation makes this a patch-today situation. Organizations that delay should assume their PaperCut infrastructure is already being probed.
