What happened
On August 27, 2026, PaperCut disclosed active exploitation affecting PaperCut NG and PaperCut MF and confirmed customer incidents. Huntress said one observed exploitation episode on August 26, 2026 lasted under two minutes. On August 28, 2026, PaperCut issued Emergency Patch Release 2 for versions 24, 25 and 26 after additional hardening work and told customers to install it even if they had applied the first emergency patch. On August 30, 2026, PaperCut published additional indicators of compromise and a timed post-exploitation command sequence. On August 31, 2026 at 4:21 p.m. AEST, PaperCut reported no new information while the investigation and hardening work continued.
CVE-2026-81578 permits unauthenticated modification of system configuration, while CVE-2026-82078 permits arbitrary Java bytecode execution when configuration parameters are manipulated. Chained together, they provide pre-authentication code execution in the PaperCut Application Server process. PaperCut treated all versions of PaperCut NG and PaperCut MF as potentially affected; Emergency Patch Release 2 covered major versions 24, 25 and 26. Huntress reproduced the chain against PaperCut NG 25.0.11.75758 and recovered exploitation evidence from customer environments, establishing that this was not merely a laboratory proof of concept.
Published server.log indicators include DB URL: jdbc:derby:memory:pwn;create=true, Database error looking up cardID: VALUES CAST(X’cafebabe and DB URL: jdbc:no:x DB Driver: <5-char random name>. Published file patterns are
Attribution posture: The cited sources name no actor, and responsibility remains unresolved.
Why this matters now
Sunday’s publication of concrete artefacts changes the closure standard. Before those indicators were available, an organisation could reasonably prioritise exposure removal and emergency patching while preserving evidence. Monday’s position is different: security teams now have exact server.log strings, file patterns, process relationships, commands and remote-access artefacts against which to test previously exposed systems. A change ticket showing Release 2 deployment does not answer whether code executed before containment.
PaperCut Application Servers sit inside trusted networks and execute under a service context. The observed path progressed from unauthenticated configuration control to operating-system discovery and installation of remote-access tooling. That placement creates a credible bridge to directory discovery, user enumeration and persistent LocalSystem access, even though the available observations do not establish a common downstream payload or broad victim count.
The first emergency patch was superseded by additional hardening on Friday, and customers running versions earlier than 24 had no same-branch emergency patch path at the publication cutoff. Organisations must therefore distinguish supported patched systems, isolated unsupported systems and systems that were exposed before either control was applied. Each group requires different evidence before risk acceptance.
The decision for security leaders
Direct infrastructure to produce one authoritative inventory covering Application Servers, Site Servers, major versions, external exposure and business owners. Do not accept a list limited to centrally managed servers; print infrastructure is frequently delegated to campuses, offices, hospitals and regional teams.
Run remediation and incident investigation as separate workstreams. Release 2 and network restrictions reduce continuing exposure, but neither establishes whether commands executed before containment. Any previously internet-reachable server needs preserved logs, endpoint review and a documented compromise disposition.
Place unsupported deployments under an explicit, time-bound exception owned by the relevant executive. If an upgrade cannot be completed immediately, enforce network isolation and define a replacement date rather than treating absence of current indicators as evidence of safety.
Evidence of closure
- Firewall evidence shows no PaperCut web interface reachable from untrusted addresses.
- Version evidence confirms Emergency Patch Release 2 on every supported server.
- Forensic review documents disposition of each published log, file and process indicator.
- Unsupported servers have an approved replacement plan and enforced network isolation.
The Security.io assessment
This lead ranked above the other selected developments because Sunday’s IOC release changed an executable Monday decision. The issue was already urgent on Friday, but the weekend evidence made patch-only closure indefensible and supplied specific artefacts defenders can search immediately. Its combination of confirmed exploitation, unauthenticated server execution, revised emergency hardening and privileged internal placement creates the highest near-term enterprise response burden in today’s agenda.
The available evidence supports confirmed active exploitation but not a conclusion that every exposed server was compromised. Huntress observed limited activity in two customer environments, while PaperCut warned that attackers may delete their temporary class, command and output files and may truncate or remove server.log. A negative search must therefore be interpreted alongside exposure history, retained telemetry and evidence quality.
The observed use of legitimate SimpleHelp and AnyDesk software should be handled as contextual evidence, not a universal block rule. Their presence is material when installed unexpectedly by pc-app.exe activity or during the exploitation window. Security teams should preserve installation metadata, Windows service creation evidence and parent-child process telemetry before removal.
Questions for the morning meeting
- Can infrastructure produce a complete inventory of PaperCut Application Servers, Site Servers, versions and internet exposure?
- Has incident response reviewed every previously exposed server independently of patch status?
- Who owns the documented exception for any unsupported or externally reachable PaperCut deployment?
- Can endpoint and logging teams prove server.log deletion or truncation would be detected?