PaperCut’s release of a second emergency patch for actively exploited vulnerabilities in PaperCut NG and MF is particularly significant because it illustrates one of the more uncomfortable realities of vulnerability response: installing the first available patch does not always mean the security problem has been completely eliminated. PaperCut originally released an emergency fix after confirming active zero-day exploitation against customer environments, but subsequent analysis by its own security team and researchers from Huntress and watchTowr uncovered multiple ways to bypass the initial remediation. PaperCut has therefore issued Emergency Patch Release 2, which includes additional hardening and must be installed even by organizations that already deployed the first emergency patch.

The vulnerabilities are now tracked as CVE-2026-81578 and CVE-2026-82078. They affect different parts of the PaperCut application but become especially dangerous when combined. CVE-2026-81578 is an authentication-bypass vulnerability affecting the PaperCut NG and MF web-management interface, while CVE-2026-82078 is an unsafe dynamic class-loading vulnerability affecting the product’s database connection utilities. Together, the vulnerabilities can allow an unauthenticated attacker to cross the authentication boundary, manipulate trusted application configuration and ultimately execute arbitrary Java code under the security context of the PaperCut Application Server.

CVE-2026-81578 carries a high-severity rating of 8.8. Under specific conditions, specially crafted unauthenticated requests can reportedly trigger administrative backend actions before the application has completed its normal authorization checks. This is a particularly dangerous category of vulnerability because it does not require an attacker to steal administrator credentials, compromise an employee account or defeat multi-factor authentication. The application itself incorrectly permits privileged activity before access validation has completed.

The security lesson extends far beyond PaperCut. Authentication and authorization controls must be completed before any sensitive backend action occurs. It is not enough for an application to eventually determine that a user lacks permission if the requested operation has already partially executed. In secure application design, access checks need to protect the operation itself rather than merely the page or interface from which the operation is normally reached.

Researchers described the vulnerable behavior as allowing a specially constructed request to reference one page for rendering while causing a component or action belonging to another page to execute. That kind of disconnect between the visible request context and the backend action can allow attackers to reach functionality that developers assumed was protected behind administrative interfaces.

This is an important reminder that URL structure and application navigation are not security boundaries. A developer may reasonably assume that an administrative function is safe because the normal user interface exposes it only after authentication. Attackers do not use applications through the interface exactly as developers intended. They construct raw requests and directly invoke backend components. Every sensitive server-side action therefore needs to independently enforce authorization.

CVE-2026-82078 is even more severe, with a critical rating of 9.4, and involves unsafe dynamic class loading inside PaperCut’s database connection functionality. The application allows database driver class names to be supplied through configuration but did not sufficiently restrict those names to an approved set of expected drivers. If an attacker can manipulate the relevant configuration, PaperCut may instantiate arbitrary Java classes that already exist on the application's classpath.

This is a powerful primitive because Java applications frequently contain large numbers of classes originating from the application itself and from third-party libraries. If an attacker can influence which class the runtime loads and initializes, a class with useful side effects may become a mechanism for code execution. This resembles the broader exploitation concept seen in unsafe deserialization and gadget-chain attacks, where legitimate code already present inside an application is repurposed to perform operations its developers never intended attackers to invoke.

The dangerous part is that CVE-2026-82078 does not need to stand alone. CVE-2026-81578 can provide the unauthenticated attacker with a path toward modifying configuration, while CVE-2026-82078 converts control over that configuration into arbitrary Java execution. One vulnerability breaks the authentication boundary and the other breaks the code-execution boundary. Chained together, they provide a path from an unauthenticated HTTP request to remote control of the PaperCut server process.

This attack chain is an excellent example of why vulnerability severity should not always be evaluated one CVE at a time. A vulnerability that merely allows configuration modification may appear less catastrophic when considered alone. A dynamic class-loading flaw may require access to configuration that ordinary attackers do not possess. Once the two weaknesses are connected, however, each supplies exactly the capability the other needs.

Attackers increasingly think in precisely these terms. They do not ask whether one vulnerability provides complete compromise. They ask whether one weakness provides access, another provides privilege and a third provides execution. Security testing therefore needs to identify relationships between vulnerabilities rather than simply producing a list of isolated findings.

The second emergency patch became necessary because researchers discovered multiple methods for bypassing PaperCut’s original fix. watchTowr reportedly reproduced the vulnerabilities fully, identified several patch bypasses and found an additional authentication-bypass issue while reviewing the initial remediation. PaperCut subsequently worked with its internal security team, Huntress and watchTowr to produce the second release with broader hardening.

Patch bypasses are especially important from a defensive perspective because they demonstrate the danger of overly narrow remediation. When developers patch only the exact request pattern or code path used by the original exploit, attackers may discover another route reaching the same sensitive function. Secure remediation needs to address the underlying trust-boundary failure rather than simply blocking one known payload.

This is similar to fixing a broken lock by preventing one particular key from turning while leaving the door capable of being opened from three other directions. The patch may stop the proof-of-concept used during testing while leaving the actual design weakness largely intact.

Security teams should therefore avoid assuming that the first patch installed on August 27 provides protection. PaperCut is explicitly instructing customers to install Emergency Patch Release 2 even if they already installed the original emergency update. Systems remaining on Release 1 should be treated as insufficiently remediated.

The second emergency patch is available for PaperCut NG and MF versions 24, 25 and 26 across Windows, Linux and macOS. Organizations running version 23 or earlier are advised to upgrade to a current supported version rather than wait for a separate emergency patch for those legacy releases.

That requirement highlights another vulnerability-management problem: unsupported software drastically reduces an organization’s options during active exploitation. When a critical vulnerability is discovered, customers running supported versions receive a patch. Customers running older releases may first need to perform a larger application upgrade before they can even address the security flaw.

Keeping enterprise applications within supported lifecycle windows is therefore part of cybersecurity preparedness. Running obsolete software may appear operationally stable until a zero-day appears, at which point the technical debt suddenly becomes an emergency migration project.

PaperCut is also instructing customers to update Site Servers and secondary or print servers to patched versions. This is important because distributed PaperCut deployments may include several components beyond the primary Application Server, and administrators could otherwise patch the central server while overlooking additional vulnerable nodes.

Other PaperCut components such as Print Deploy and Mobility Print are not affected by these specific vulnerabilities and do not require emergency updates for this issue. That distinction matters because security response should remain precise. Emergency patching should focus on components that actually contain the vulnerable functionality rather than creating unnecessary operational disruption across every product carrying the PaperCut name.

The continued recommendation to restrict PaperCut web interfaces to trusted IP addresses remains equally important even after patching. PaperCut is still advising organizations to use firewall rules, network access controls or equivalent mechanisms to prevent the Application Server’s web interfaces from being reached directly from untrusted internet addresses.

This advice should be treated as an architectural improvement rather than merely a temporary workaround. If a print-management administration interface does not need to be accessible from the entire internet, it should not be exposed there. Removing unnecessary exposure provides protection against future vulnerabilities that have not yet been discovered, not just CVE-2026-81578 and CVE-2026-82078.

The incident demonstrates the difference between vulnerability remediation and attack-surface reduction. A patch removes one known defect. Restricting access removes entire categories of potential attackers from reaching the application at all. Both controls are valuable, but they solve different problems.

Organizations frequently assume that because an application is patched it can safely remain globally accessible. That approach creates a recurring cycle: each new zero-day turns the internet-facing service back into an emergency. Systems with limited business need for public access should instead sit behind VPN, ZTNA, administrative networks or source-IP restrictions.

The PaperCut Application Server is particularly sensitive because it acts as the central control point for the print-management environment. It manages configuration, user information, print policies and integrations with other enterprise systems. Successful code execution inside this process therefore provides attackers with considerably more opportunity than compromising an ordinary employee workstation.

Depending on configuration, the PaperCut server may communicate with Active Directory or LDAP, databases, print servers, email infrastructure and other internal services. Attackers obtaining execution on that server may therefore attempt to harvest service-account credentials, directory information or configuration secrets that facilitate lateral movement.

This is why successful exploitation should be treated as a possible enterprise compromise rather than merely a print-management incident.

Huntress has already observed limited exploitation in two customer environments. In those incidents, attackers reportedly executed Base64-encoded commands after exploitation to determine the account under which the PaperCut process was running and identify the operating system using commands equivalent to `whoami` and `ver`.

Those commands appear simple, but they are classic post-exploitation reconnaissance. Attackers frequently begin by determining who they are, what privileges they possess and which operating system they have compromised before selecting the next stage of their attack.

The use of Base64 encoding is similarly common. Encoding commands can obscure obvious malicious strings from simple detection mechanisms and make payloads easier to transport through application fields or scripting environments. Base64 itself is not malicious, but unexpected decoding followed by shell execution from a server process deserves scrutiny.

Security teams should therefore monitor the PaperCut server for unusual child processes originating from the legitimate PaperCut application process, particularly `pc-app.exe` on Windows. A print-management application suddenly launching command interpreters, PowerShell or unfamiliar utilities should be treated as highly suspicious.

Process lineage matters because attackers increasingly abuse legitimate application processes. Detecting the presence of `pc-app.exe` itself is meaningless because it is supposed to exist. The useful security question is what that process begins doing after receiving a malicious request.

The previously published indicators remain relevant. Administrators should investigate missing, unexpectedly truncated or deleted `server.log` files as well as unusual log entries involving database driver errors. However, PaperCut continues to warn that absence of these indicators does not prove that a server was not compromised.

That qualification is crucial. Indicators of compromise represent artifacts observed during known attacks, not universal evidence that every exploit must generate. An attacker may use different payloads, bypass logging, delete evidence successfully or modify exploitation techniques after reading public detection guidance.

Organizations should therefore avoid the dangerous logic of searching for two strings, finding nothing and declaring the environment clean. Compromise assessment needs to examine broader endpoint, identity and network behavior.

Centralized logging becomes especially important because attackers with code execution may attempt to manipulate local application logs. PaperCut, operating-system, authentication and EDR telemetry should ideally be forwarded to a remote logging environment where the compromised Application Server cannot alter historical evidence.

Firewall and network-flow data can provide additional visibility. Security teams should examine whether PaperCut servers initiated connections to unfamiliar internet destinations, particularly around suspicious application events.

Unexpected outbound connections can indicate secondary payload downloads, command-and-control communication or data exfiltration. A print-management server generally has relatively predictable communication requirements, making unusual destinations potentially valuable signals.

Egress filtering would reduce this risk further. PaperCut servers should not receive unrestricted outbound internet access merely because allowing everything is operationally convenient. Explicitly permitting required destinations can significantly reduce an attacker’s ability to convert initial code execution into persistent remote control.

Internal segmentation deserves similar attention. A compromised PaperCut server should not automatically be able to reach every server and management interface in the enterprise. Communication to directory services, databases and print infrastructure should follow documented policy rather than relying on a flat internal network.

This is especially important because attackers gaining code execution may attempt credential theft and lateral movement immediately after discovering their privilege level.

Service accounts used by PaperCut should follow strict least privilege. If the application runs under a highly privileged domain account, successful RCE may immediately provide the attacker with authority far beyond the PaperCut server. The difference between a restricted service identity and a domain administrator account can determine whether exploitation remains a server compromise or becomes domain compromise.

Organizations should therefore review both the operating-system identity of the PaperCut service and any credentials stored within its configuration. Integration accounts should have only the rights required for printing and directory queries.

Credentials accessible from a suspected compromised server should be rotated where appropriate. Patching the application prevents reuse of the original vulnerability but does not invalidate passwords or tokens the attacker may have already extracted.

This is one of the most important lessons from active exploitation incidents: remediation has two timelines. One concerns the software vulnerability. The other concerns everything the attacker may have done while the vulnerability remained exploitable.

Installing Emergency Patch Release 2 addresses the first timeline.

Forensic investigation addresses the second.

Organizations that operated public-facing PaperCut servers before patching should therefore consider preserving relevant logs and performing historical review even if the server currently appears healthy. The initial exploitation reportedly occurred before the vulnerabilities and CVE identifiers were publicly disclosed, meaning attackers possessed a temporary knowledge advantage over defenders.

The incident also demonstrates how quickly zero-day response can evolve. PaperCut first received information from a university customer and its incident-response team, reproduced the vulnerability, issued an emergency patch and then received additional analysis revealing patch bypasses. Within roughly a day, defenders moved from an unknown actively exploited weakness to two identified CVEs and a second hardened patch.

That is coordinated vulnerability response working under significant pressure, but it also illustrates why organizations need rapid patch-management capabilities. Customers cannot assume the first advisory will contain the final technical picture.

Security teams need processes capable of absorbing updated guidance without treating every change as an entirely new project. When a vendor says yesterday’s emergency patch is no longer sufficient, systems should be updated again quickly.

This is particularly challenging in large environments where printing infrastructure is distributed across many sites. Administrators may have only just finished deploying Release 1 when Release 2 arrives. Unfortunately, attackers are not generally sympathetic to change-management fatigue.

Automated inventory becomes essential here. Organizations should be able to identify all PaperCut Application Servers, Site Servers and secondary servers together with their current version and patch state.

Without centralized visibility, security teams risk leaving one forgotten regional server vulnerable even after headquarters has been fully patched.

Test and disaster-recovery environments should also be included. Non-production systems are frequently excluded from urgent remediation because they are considered less important, yet they may still contain credentials and network connectivity useful to attackers.

An exposed test PaperCut server connected to the production directory can become a perfectly adequate entry point.

The current situation also reinforces the importance of validating patches rather than merely recording installation. Security teams should confirm that Release 2 is actually active on every system rather than assuming a deployment job completed successfully.

Configuration-management tools, vulnerability scanners or product version reporting can help verify that the corrected build is running.

Rollback processes deserve attention as well. If an operational issue later causes administrators to restore a server snapshot containing the original emergency patch or an entirely unpatched version, the vulnerability can silently return.

Security state should therefore be validated after restoration just as carefully as after normal deployment.

The discovery of multiple patch bypasses also provides a valuable lesson for software vendors. Security fixes for authentication vulnerabilities need adversarial testing around adjacent request paths, not only confirmation that the original proof of concept stops working.

Researchers reviewing a patch will deliberately ask how the protected backend action can still be reached through alternative endpoints, parameter combinations or component mappings.

Fixing the symptom rather than the trust boundary frequently produces exactly the situation PaperCut has now encountered: the published exploit stops working, but another path remains.

External security research is valuable precisely because independent researchers approach the patch without the assumptions of the developers who designed the original feature. Huntress and watchTowr were able to investigate the application from the attacker’s perspective and identify alternate paths requiring further hardening.

The incident therefore provides a useful argument for collaboration between vendors, incident-response firms and vulnerability researchers during active exploitation.

Customers benefit when defenders share technical information quickly enough to improve remediation rather than treating security research as an adversarial relationship.

There is another broader lesson in the dynamic class-loading flaw. Modern applications often expose powerful configuration functionality that can indirectly influence code execution. A setting described as “database driver class” may appear harmless because administrators normally select from several expected values. But if the application accepts arbitrary class names, configuration becomes part of the execution boundary.

Security teams should therefore examine configuration interfaces with the same suspicion applied to executable input. Any user-controlled setting that identifies classes, scripts, templates, filesystem paths or plugin names can become dangerous if insufficiently constrained.

Allowlisting is particularly important for values intended to select from a small known set. If PaperCut supports a limited collection of database drivers, the application should accept only those approved identifiers rather than attempting to load whichever Java class name a configuration value happens to contain.

This follows the broader secure-design principle of positive validation: define what is allowed rather than trying to enumerate everything malicious.

The incident is also a reminder that enterprise Java applications inherit security risk from the enormous classpaths they carry. The more libraries present, the greater the number of potentially interesting classes an attacker may try to abuse after gaining influence over dynamic loading.

Dependency minimization can therefore reduce attack surface even when the underlying vulnerability lies elsewhere.

The PaperCut attack chain resembles patterns seen repeatedly across enterprise software: attackers first obtain a way to modify trusted configuration, then exploit a feature that assumes configuration is controlled only by administrators.

That assumption collapses once the first vulnerability exists.

Secure applications should therefore treat even internally stored configuration defensively when it is consumed by highly privileged or code-loading functionality. Trust should be minimized across internal boundaries just as it is across external ones.

The continued targeted exploitation also means organizations should expect attack techniques to evolve as technical details spread. Initially, only the actors who discovered or obtained the zero-day understood the exploit path. Public disclosure of the CVEs and researcher analysis lowers the knowledge barrier for additional attackers.

Historical experience with PaperCut makes this especially relevant. In 2023, attackers widely exploited CVE-2023-27350, and activity was eventually associated with ransomware groups including Clop, LockBit and Bl00dy as well as Iranian state-backed actors.

The current vulnerabilities are not the same as the 2023 flaw, and there is currently no evidence linking those groups to the 2026 attacks. But the earlier incident shows that PaperCut servers become attractive targets once reliable exploitation techniques circulate.

Organizations should therefore not interpret the description of current attacks as “limited and targeted” to mean the risk will necessarily remain limited.

Targeted exploitation can become commodity exploitation quickly after exploit details emerge.

The most important immediate defensive action is therefore unambiguous: install Emergency Patch Release 2 on PaperCut NG/MF 24, 25 and 26 even if Release 1 was already installed. Environments running version 23 or older should move to a currently supported version.

Patch the primary Application Server, Site Servers and secondary or print servers where applicable.

Then verify the update.

Afterward, restrict the PaperCut web interface to trusted networks or addresses wherever public access is not necessary.

And for systems that were internet-exposed before remediation, perform compromise assessment rather than assuming the update rewrites history.

The broader lesson from this incident is that patching is a process, not an event. Vendors sometimes need to refine security fixes as researchers identify alternate paths, especially during rapidly evolving zero-day investigations.

This should not cause organizations to distrust patches. It should cause them to maintain enough operational agility to deploy corrected patches quickly when new information emerges.

A security team that installed Release 1 immediately did the right thing with the information available at the time.

The mistake would be assuming that yesterday’s correct action means today’s updated guidance can be ignored.

PaperCut’s second emergency patch ultimately demonstrates the difference between closing an exploit and eliminating a vulnerability class. The first fix addressed the initially understood attack. Further research showed that attackers could still navigate around parts of that protection.

Release 2 attempts to harden the broader boundary.

For defenders, the central takeaway is simple: when a vendor dealing with active exploitation tells customers that the first emergency patch is no longer enough, the correct patch level becomes the second one immediately.

In cybersecurity, unfortunately, “we patched yesterday” is not a security control if attackers discovered another door this morning.

PaperCut has released a second emergency security update for two actively exploited vulnerabilities in its PaperCut NG and MF print management software after researchers discovered multiple ways to bypass the initial fixes. [...]

Source: PaperCut releases second emergency patch for exploited flaws via Bleeping Computer — published 28 Aug 2026.