Security.io Intelligence DeskThursday, 3 September 2026
Independent analysis
for security executives
The Security.io DailyThe Weekday Intelligence Edition
Free to readers
Supported by underwriters
Vulnerability Management · Lead decision brief

PaperCut’s Sunday indicators make compromise review mandatory

Sunday’s indicators transformed the PaperCut emergency from a patching task into a forensic one. Internet-facing NG and MF servers require isolation, Emergency Patch Release 2 verification and evidence-led compromise review before closure.

Vulnerability ManagementIncident ResponseNetwork Security
Why this leads today

This ranked first because the material change occurred on Sunday: PaperCut released exact compromise artefacts and a post-exploitation sequence after Friday’s second emergency patch. That changed Monday’s leadership decision from accelerated patching to dual-track containment and forensic verification. It outranked the other selected stories through confirmed exploitation, privileged server execution and an evidence set that enables immediate enterprise action.

Read first

PaperCut confirmed active exploitation of an unauthenticated PaperCut NG/MF chain and issued two emergency patch iterations before the weekend.

Act now

Remove public access to every PaperCut Application Server pending verified Release 2 deployment.

Accountable owner

CISO with infrastructure, endpoint security and incident response leads

Decision horizon

Immediate; begin during the first two hours of Monday and maintain incident status until exposed servers pass forensic review.

AssessmentHigh confidence
Emerging riskFurther patch revisions, evidence of exploitation against Release 2, additional payload families, malicious source infrastructure or broader victim telemetry.

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 \server\lib<5-char-name>.class, \server\data\content<5-char-name>.cmd and \server\data\content<5-char-name>.out. Observed activity included pc-app.exe or pc-app spawning cmd.exe, then running whoami & ver, tasklist, nltest /dclist:, and quser & dir c:\users before downloading ace.exe from sendit.sh/Gg7Rp/ace.exe and AnyDesk.exe from download.anydesk.com/AnyDesk.exe into C:\ProgramData. The observed SimpleHelp persistence was a Windows service named Remote Access Service running C:\ProgramData\JWrapper-Remote Access\JWAppsSharedConfig\restricted\SimpleService.exe as LocalSystem. No malicious source IP address was published in the cited sources.

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?

Related intelligence

Shared decision context