PaperCut published an urgent advisory on August 27, 2026 after confirming active exploitation against PaperCut NG and PaperCut MF Application Servers. The response moved quickly. An initial emergency patch arrived on August 28, a second release added more hardening, and Emergency Patch Release 3 superseded both earlier packages on September 1.
By September 2, PaperCut was reporting a second attack wave against public servers that were not fully patched. The company also said the newer activity involved more sophisticated post-compromise behavior than it observed during the first days of the incident.
That sequence changes the operational task. Administrators need to install the current emergency release, even if they already applied Release 1 or Release 2. They also need to determine whether the server was exposed before the current patch was installed and whether attackers used that window.
A successful update closes the known attack path. It does not remove remote access software, restore deleted logs, reverse configuration changes, or prove the Application Server was never compromised.
What the PaperCut exploit chain does
The attack combines two vulnerabilities affecting all versions of PaperCut NG and PaperCut MF.
CVE-2026-81578 is an authentication bypass in the web management interface. Under specific conditions, an unauthenticated request can trigger an administrative backend action before access validation finishes. PaperCut says this can let a remote attacker modify certain system configurations.
CVE-2026-82078 is an unsafe dynamic class-loading flaw in PaperCut's database connection utilities. The application can instantiate database driver classes from configurable names without limiting the selection to an approved list. If an attacker can first alter the relevant configuration, the flaw can execute arbitrary Java bytecode available to the Application Server process.
The first vulnerability provides the configuration control needed to reach the second. Chained together, they allow pre-authentication remote code execution in the security context of the PaperCut service.
Huntress reproduced the complete chain against a standard PaperCut NG 25 server. Its researchers observed exploitation in two customer environments and recovered commands used to identify the current user, Windows version, and running processes. The activity seen in those initial cases was limited, but later updates from PaperCut described attackers downloading remote access tools on systems where execution was not stopped.
The distinction between the two CVEs matters for defenders. CVE-2026-82078 has a high privilege requirement when considered alone because an attacker must control configuration parameters. CVE-2026-81578 supplies that control without authentication. Reviewing either flaw in isolation understates the practical risk of the chain.
Release 3 replaces the earlier patches
PaperCut's current direction is clear: internet-facing Application Servers on versions 24, 25, or 26 should install Emergency Patch Release 3, including servers that already received an earlier emergency release. Release 3 is cumulative, so administrators do not need to install Releases 1 and 2 first.
Release 3 adds further hardening and fixes two regressions introduced during the emergency response. One affected SAML login flows. The other affected legacy Microsoft SQL Server drivers used for external card lookups.
Organizations running version 23 or earlier do not have a Release 3 package. PaperCut recommends upgrading those installations to the latest version. This may be more disruptive than applying an in-branch patch, but leaving an unsupported branch online is not a reasonable substitute.
The scope also extends beyond the primary Application Server. PaperCut says Site Servers and secondary or print servers should be updated to a patched version. Mobility Print, Print Deploy server components, and client software are not affected by this advisory.
Administrators should use the live PaperCut bulletin to obtain the correct build and checksum. The advisory remained active on September 2, and its instructions changed several times during the response. A downloaded package or internal ticket that was accurate on August 28 may no longer represent the required state.
Public exposure sets the response priority
The immediate containment step is to remove PaperCut's web interfaces from untrusted internet access. PaperCut recommends limiting access to trusted IP addresses through firewall rules, network controls, or equivalent restrictions.
Internet isolation should happen even when the team has not found suspicious activity. It reduces the chance of exploitation while administrators plan the update and investigate the server.
Private placement lowers exposure, but it does not settle the question by itself. Teams should confirm whether the server was ever publicly reachable during the relevant period. Check current firewall policy, historical rule changes, reverse-proxy configuration, network address translation, cloud security groups, external scanning data, and documentation from any MSP that manages the environment.
Do not rely only on the administrator's intended architecture. A server described as internal may still be reachable through an old port-forwarding rule, a temporary troubleshooting change, or an inherited cloud configuration.
The Canadian Centre for Cyber Security reported that CISA added both CVEs to the Known Exploited Vulnerabilities catalog on August 31. For organizations with an exposed Application Server, this should take priority over ordinary monthly maintenance.
Preserve evidence before it disappears
Patching and evidence preservation can conflict during an active incident. An exposed server should not remain reachable while responders try to build a perfect forensic image. Restrict access first. Then capture the available evidence before an upgrade, restart, cleanup action, or attacker removes more of it.
A useful collection set includes:
- The complete PaperCut
server/logsdirectory, including timestamps and file metadata - The Application Server version, installation path, service account, and current configuration
- Nondefault database, authentication, user lookup, and integration settings
- Endpoint process trees involving
pc-app.exe,pc-app, or associated Java processes - Recently created services, scheduled tasks, autoruns, executable files, and Java class files
- Firewall, reverse-proxy, web application firewall, DNS, authentication, and network-flow logs
- EDR alerts and isolation events involving the Application Server
Huntress observed malicious code deleting its output and PaperCut's server.log. PaperCut also warns that attacker-created files may be cleaned up during the intrusion. Missing artifacts therefore cannot be treated as proof that exploitation did not occur.
If an outside provider manages PaperCut, request preserved evidence rather than a statement that the system was patched. The useful record includes when public access was removed, when each patch was installed, which components were updated, what logs were retained, and who reviewed the server for compromise.
Hunt for Application Server abuse
PaperCut and Huntress have published several investigation leads. Teams should treat them as starting points, not as a complete detection package.
Review server.log for database errors involving unexpected JDBC values, including references to jdbc:no:x, jdbc:derby:memory:pwn, or card ID lookups containing suspicious casts. Check for missing, truncated, or recently recreated log files.
Look under the PaperCut installation directories for unexpected five-character filenames. Reported patterns include Java .class files under server/lib and matching .cmd or .out files under server/data/content. The names can vary, and attackers may delete them after execution.
At the process level, investigate pc-app.exe, pc-app, or Java spawning command shells and system discovery tools. Observed commands included whoami, ver, tasklist, nltest, quser, and PowerShell downloads. Normal administrative scripts may use some of these commands, so parent process, timing, user context, and network destination matter.
PaperCut's September 2 guidance also identifies a Windows service named Remote Access Service running a SimpleHelp component from C:\ProgramData\JWrapper-Remote Access, along with unexpected AnyDesk installations, as possible signs of post-compromise access. Their presence deserves incident-response handling, not routine software cleanup.
Widen the hunt beyond the Application Server. Review outbound connections, new remote administration software, service-account activity, authentication from the server to other systems, and changes made after the earliest confirmed public exposure. Remote code execution gives an attacker a starting point. The later scope depends on the server's privileges and network reach.
Decide when to rebuild
PaperCut recommends securing current backups, wiping and rebuilding the Application Server, and restoring a clean backup taken before the suspicious activity when compromise is suspected. That guidance is stronger than deleting a payload and returning the server to production.
A rebuild should be considered when responders find unexplained child processes, attacker-created classes, remote access tooling, suspicious services, deleted logs, unauthorized configuration changes, or network activity consistent with command execution. It may also be the safer decision when the server was exposed during active exploitation but available telemetry is too weak to support a credible investigation.
After a rebuild, rotate credentials the server could access or store. Review the PaperCut service account, local and domain administrator credentials used on the host, database credentials, integration secrets, and accounts used to administer the application. The exact scope should follow the evidence and the server's privileges.
Document uncertainty directly. "No indicators found" means the review did not find the published indicators in the available data. It does not mean the system is proven clean, especially when logs were missing or retention did not cover the exposure window.
Close the operational gap
This incident exposes a familiar weakness in vulnerability response. Teams often track the CVE and patch ticket but lose the connection to internet exposure, evidence collection, affected components, investigation results, system ownership, and the decision to rebuild or retain the server.
A complete closure record should show the PaperCut product and version, every affected server, historical exposure, containment time, Release 3 installation, post-install validation, evidence retained, indicators reviewed, credential actions, and the person who accepted the final disposition.
If your team needs current endpoint context to identify systems running affected software and verify that remediation is complete, Meridian Vulnerability Management connects software exposure, affected hosts, remediation work, and verification inside CulperIQ. For PaperCut, the immediate objective is specific: remove public access, install Release 3, investigate the Application Server, and rebuild it when the evidence no longer supports trust.
