What happened
At 9:42 a.m. AEST on 27 August 2026, an education-sector customer reported that a PaperCut MF server appeared compromised. The first customer’s logs showed real code execution on the PaperCut MF server. PaperCut initially tested whether the activity used an older, already corrected weakness, but the evidence pointed to a different path. The company declared its highest-priority incident posture and began reproducing a previously unknown exploit chain using evidence preserved by the customer’s security and digital-forensics teams.
At 5:05 p.m. AEST on 27 August 2026, a second organisation in the same region reported similar activity and supplied additional logs. PaperCut described an authentication bypass in the core product followed by a multi-stage chain using database-driver behaviour, arbitrary file writing and Java class loading to execute a payload. PaperCut treated all versions of PaperCut NG and PaperCut MF as potentially impacted at the edition cutoff. PaperCut told customers to remove internet-facing PaperCut Application Servers from the internet while mitigation and patching proceeded.
At 2:10 a.m. AEST on 28 August 2026, PaperCut released emergency patches for versions 25 and 26, with version 24 patches following later that day. Emergency patches were available for PaperCut NG and PaperCut MF versions 24, 25 and 26 by the edition cutoff. The vendor had not published the complete technical chain, judging that premature detail could increase risk while customers remained exposed. The existence of patches therefore addresses known vulnerable code but does not establish whether any server was exploited before isolation or remediation. The cited source did not publish the relevant file hashes described as File indicators.
Why this matters now
PaperCut servers occupy a useful operational position: they are broadly connected to users, printers, directories and administrative services, while their web interfaces are sometimes published for remote use. Confirmed code execution therefore changes the decision from vulnerability prioritisation to incident containment. An exposed server that has been patched but not investigated may still retain attacker-created files, altered configuration, credentials or access paths that survive remediation.
The vendor’s response also shows how quickly the situation changed. The first customer preserved logs by isolating the virtual machine, a second customer supplied additional evidence and PaperCut moved from investigating an apparent compromise to reproducing a previously unknown exploit chain and issuing emergency patches. Organisations that wait for complete indicators or a polished retrospective surrender the narrow period in which volatile evidence and clear service-owner recollection remain available.
The decision for security leaders
Run two workstreams in parallel. Infrastructure owners should isolate and update every affected server, while incident response preserves logs, virtual-machine snapshots, configuration, database settings and surrounding identity telemetry. Do not allow a successful version check to close the incident record for a server that was internet-facing before remediation; patch state and compromise state answer different questions and require different evidence.
Set a short, explicit exception process for sites that cannot interrupt printing. The exception should identify the accountable business owner, compensating network controls, monitoring coverage and an expiry time measured in hours rather than an ordinary maintenance cycle. Any server lacking reliable logs or ownership should receive a higher investigative priority because absence of telemetry reduces assurance rather than indicating absence of exploitation.
Evidence of closure
- Asset inventory shows no unknown PaperCut Application Servers and records each server’s exposure state.
- Version evidence confirms every supported server runs the current emergency patch for its deployed major release.
- Firewall or proxy evidence confirms no unintended PaperCut administrative interface remains internet-accessible.
- Forensic review documents a clean disposition or an incident case for every previously exposed server.
The Security.io assessment
PaperCut and Rapid7 had not published validated malicious IP addresses, domains or URLs by the edition cutoff. No malicious file hashes or payload filenames had been published by the edition cutoff. Attribution posture: PaperCut said it knew nothing about the attackers or their motivations, so no actor attribution had been established by the edition cutoff. Defenders therefore cannot depend on a narrow blocklist or actor-specific detection package; exposure history and host-level evidence must drive triage.
The strongest positive signal is the speed with which the first customer isolated its virtual machine and preserved logs, enabling reconstruction of the chain. The remaining enterprise risk is uneven execution across distributed sites, schools, offices and managed-service arrangements. A central team may report complete patching while forgotten, partner-managed or temporarily disconnected servers remain exposed. Closure should be based on a reconciled asset inventory and server-by-server forensic disposition, not the number of patches deployed.
Questions for the morning meeting
- Which PaperCut Application Servers remain reachable from the internet?
- Can owners prove that emergency patches are current for every deployed major version?
- Which previously exposed servers have received a documented compromise assessment?
- Who can authorise immediate isolation where patching would interrupt printing services?