PaperCut has released fully tested security maintenance updates for PaperCut NG and PaperCut MF, replacing the three emergency patches issued after active exploitation of two serious vulnerabilities in late August. The new recommended versions are PaperCut NG/MF 26.0.5, 25.0.13 and 24.1.10. PaperCut says these maintenance releases include every security fix delivered through Emergency Patch Releases 1, 2 and 3, additional hardening, updated third-party dependencies and the benefit of its full standard QA and regression-testing process. Customers running any emergency patch build are now explicitly being told to move to one of the new maintenance releases, while organizations that never patched are being urged to upgrade immediately. 

The two vulnerabilities at the center of the incident are CVE-2026-81578 and CVE-2026-82078, and their interaction is more important than their individual descriptions suggest. CVE-2026-81578 is an improper access-control vulnerability in the PaperCut web management interface, while CVE-2026-82078 is an unsafe dynamic class-loading flaw in the database connector used by the external card and ID lookup functionality. PaperCut rates CVE-2026-82078 Critical at CVSS 9.4 because an attacker capable of manipulating the relevant system configuration can cause the application to instantiate attacker-selected Java classes from the application classpath, potentially executing arbitrary Java bytecode under the security context of the PaperCut server process.

The attack chain is what turned these flaws into something substantially more dangerous. Researchers observed attackers combining weaknesses to reach remote code execution without authentication, prompting CISA to add the vulnerabilities to the Known Exploited Vulnerabilities Catalog and require federal agencies to remediate them by September 14. In other words, defenders are not dealing with a vulnerability that merely scores highly on a theoretical severity scale. Attackers have already demonstrated that the weaknesses can be assembled into a practical intrusion path against internet-facing PaperCut servers.

PaperCut’s own telemetry gives defenders a useful picture of what happens after exploitation. In confirmed incidents, attackers executed reconnaissance commands such as `whoami`, `ver`, `tasklist`, `nltest /dclist:`, `quser`, and directory enumeration before downloading additional remote-access tooling. PaperCut observed PowerShell being used to fetch a payload named `ace.exe`, followed by installation of a SimpleHelp agent as a Windows service named “Remote Access Service” running as LocalSystem. Attackers later downloaded AnyDesk into `C:\ProgramData`.

That sequence should look familiar because it resembles a conventional post-exploitation workflow rather than anything specifically related to printing. Once the application server has been compromised, the fact that it originally managed printers becomes almost irrelevant. The attacker enumerates users and domain controllers, installs persistent remote-access tooling and begins exploring the rest of the network. A PaperCut server therefore becomes useful not because attackers desperately want to manipulate print queues, but because it can provide a privileged Windows foothold inside the enterprise.

This is particularly important in education, government and enterprise environments where PaperCut servers may sit close to Active Directory, file services and large populations of user endpoints. Print-management infrastructure is often treated as operational middleware rather than high-value security infrastructure. Yet these servers commonly integrate with directory services, authentication systems, databases and endpoint printing workflows, giving attackers both network connectivity and potentially valuable credentials after compromise.

The active exploitation also shows why internet exposure matters so much. PaperCut has repeatedly urged customers to place Application Servers behind firewalls and remove unnecessary direct internet reachability. The vendor reports that new compromises have slowed significantly as customers have patched or placed servers behind firewalls, but it also warns that publicly reachable, unpatched servers continue to be targeted and that later post-compromise activity has become more sophisticated than what was seen during the first days of the campaign.

That progression is predictable. Early exploitation of a newly disclosed vulnerability is often noisy because multiple actors race to scan the internet and establish access. As the campaign matures, more capable operators begin refining persistence, credential theft and lateral movement. The shrinking pool of vulnerable servers does not necessarily reduce the danger to the organizations still exposed. In some cases it simply means the remaining vulnerable systems are increasingly being targeted by adversaries who know exactly what they want to do after getting in.

PaperCut’s emergency response also provides a useful case study in how real-world patching actually works. The first emergency release focused on rapidly mitigating the active exploitation. Release 2 introduced additional hardening after PaperCut worked with its internal team and outside researchers including Huntress and watchTowr. Release 3 then corrected regressions affecting SAML login flows and legacy Microsoft SQL Server drivers used for external card lookups while adding still more mitigation against potential attack chains.

From the outside, three emergency patches in less than a week can look untidy. From a security-response perspective, it reflects an unavoidable trade-off. When exploitation is already occurring, the vendor can either hold the patch until every regression and secondary attack path has been comprehensively tested, or provide a mitigation quickly and refine it as new information becomes available. PaperCut explicitly says it chose the second approach because delaying protection while attackers were active would have created greater risk.

That is a reasonable strategy, but it transfers some operational burden to customers. Administrators who installed Release 1 could not simply declare victory. They needed Release 2, then Release 3, and now the fully tested maintenance release. This is exactly why emergency vulnerability response needs lifecycle tracking rather than a binary “patched/unpatched” status. The security team must know not only whether something was installed, but whether the installed mitigation has subsequently been superseded.

Organizations should therefore treat emergency patches as temporary security states unless the vendor explicitly says otherwise. Patch-management systems should track vendor advisories after deployment and identify when a workaround, hotfix or interim build has been replaced by a permanent release. Otherwise, infrastructure can remain indefinitely on emergency code that was never intended to become the long-term baseline.

The new maintenance releases are preferable because they have gone through PaperCut’s complete QA process and incorporate not only the CVE fixes but additional hardening discovered during the investigation. Version 26.0.5, for example, addresses both CVE-2026-81578 and CVE-2026-82078, moves external database Card/ID lookup configuration into `security.properties`, updates third-party dependencies and includes further security improvements identified during internal review. Equivalent security changes are present in the 25.0.13 and 24.1.10 maintenance branches.

Administrators using the external database Card/ID lookup functionality should pay particular attention to the configuration change. PaperCut has moved that configuration into a more security-focused properties file, and organizations using the feature will need to reconfigure it after upgrading. This is a good example of why security releases sometimes require more than simply installing binaries. Hardening may deliberately alter configuration assumptions, and teams need to validate that both security and business functionality continue to behave as intended afterward.

The underlying unsafe dynamic class-loading issue is also worth examining from a secure-development perspective. CVE-2026-82078 exists because PaperCut could instantiate database driver classes based on configurable class names without restricting those values to an approved allowlist. Dynamic loading is extremely useful in Java applications because it enables flexible plugin and driver architectures, but it becomes dangerous when attacker-influenced input determines which code is instantiated.

The correct design principle is simple: when applications need dynamic functionality, the set of permitted classes should be explicitly constrained. A system that expects a small number of approved database drivers should not allow arbitrary class names simply because those classes exist somewhere on the classpath. Flexibility at that boundary is effectively code-selection authority, and code-selection authority should be treated as code execution.

The authentication or access-control weakness represented by CVE-2026-81578 illustrates the other half of the attack chain. A dangerous administrative capability may appear acceptable if developers assume only privileged users can reach it. If an access-control flaw later exposes that functionality to unauthenticated callers, the supposedly safe internal feature suddenly becomes remotely exploitable. This is why sensitive backend operations should retain their own strict validation rather than depending entirely on the outer authentication layer to protect them.

The combination of the two flaws therefore demonstrates a common architectural failure mode.

One bug reaches functionality the attacker should never have been able to access.

The second turns that functionality into code execution.

Neither boundary can safely assume the other boundary will always hold.

PaperCut’s incident indicators also reinforce why organizations should perform compromise hunting even after applying the new maintenance release. The presence of SimpleHelp’s `SimpleService.exe` in the observed path, a Windows service named “Remote Access Service,” or unexpected AnyDesk installations can indicate post-compromise persistence. However, PaperCut explicitly warns that absence of these indicators does not prove a system was never compromised.

That qualifier matters because attackers do not have to use the same tooling forever. Once exploitation details become widely understood, different operators can deploy entirely different payloads. Static indicators such as filenames and IP addresses are useful for immediate hunting, but defenders should also look for the behavior underlying the attack: suspicious process creation from the PaperCut service, unexpected PowerShell or shell execution, unusual outbound downloads, service creation, remote-access software installation and Active Directory reconnaissance.

Systems that were internet-facing during the exploitation window deserve particularly close scrutiny. Researchers advising on the incident went as far as recommending that organizations whose PaperCut servers were exposed treat them as potentially compromised and perform incident-response procedures rather than relying solely on patch installation. That may sound aggressive, but once unauthenticated RCE has been actively exploited, the cost of assuming a vulnerable server was untouched can be much higher than the cost of investigating it.

Credential rotation may also be necessary where exploitation is confirmed. A compromised PaperCut Application Server may have access to directory-service accounts, database credentials or integration secrets depending on how the organization configured it. Security teams should identify what the PaperCut service account and host could read, rather than limiting their response to the application’s own administrator password.

External logging becomes particularly important for the same reason. If attackers obtain code execution under a highly privileged server process, locally stored logs can no longer be treated as completely authoritative. Application, authentication, process and network telemetry should be forwarded to independent SIEM or logging infrastructure so investigators retain evidence even if an attacker attempts to clean up the compromised host.

Segmentation provides another useful defense. A PaperCut server needs to communicate with printers, users, directory services and supporting infrastructure, but it should not automatically have unrestricted access to every part of the network. If compromise occurs, network controls should make it difficult for the attacker to move directly from print infrastructure into domain controllers, backup servers or other critical systems.

The disclosure also reinforces the importance of minimizing direct internet exposure for infrastructure software that was never designed to function as a public application gateway. If external user functionality is required, organizations should consider whether it can be published through a controlled reverse proxy, VPN or other access layer rather than exposing the complete management application directly.

The broader lesson from PaperCut’s response is therefore not merely about two CVEs. It is about vulnerability-response maturity. First came active exploitation. Then an emergency mitigation. Then additional hardening. Then regression fixes. And finally a fully QA-tested maintenance release. 

Security teams that installed the first patch and stopped monitoring the advisory would now be running a superseded build. The same is true in reverse for organizations that waited for the polished maintenance release while their internet-facing server remained vulnerable during active exploitation. The right approach is neither “patch immediately and forget” nor “wait until the vendor is completely finished.”  It is rapid risk reduction followed by deliberate stabilization.

Install the emergency mitigation when attackers are already exploiting the flaw. Continue tracking the vendor.  Replace the temporary patch when the tested release arrives.  And if the system was exposed before remediation, investigate whether the attacker arrived first. Because in an active exploitation event, vulnerability management is not a single patch. It is a sequence of decisions.

PaperCut on Thursday released a new security maintenance release that replaces all previously published emergency patches that were pushed to address two security flaws that have come under active exploitation. The software development company said PaperCut NG/MF versions 26.0.5, 25.0.13 and 24.1.10 are now available for customers to download. "These are Regular Maintenance Releases (MR) that

Source: PaperCut Replaces Emergency Patches With Fixes for Two Actively Exploited Flaws via The Hacker News — published 11 Sep 2026.