CISA’s addition of CVE-2026-81578 and CVE-2026-82078 to the Known Exploited Vulnerabilities catalog should be treated as a significant escalation of the PaperCut NG/MF security incident because the two vulnerabilities are not merely theoretically exploitable. There is now sufficient evidence of real-world exploitation for both flaws to enter the KEV catalog, meaning defenders are dealing with an active attack path rather than a vulnerability-management exercise based only on CVSS scores or proof-of-concept research. The two weaknesses are particularly dangerous when considered together because CVE-2026-81578 can allow an attacker with no prior authentication to manipulate sensitive PaperCut configuration, while CVE-2026-82078 can use control over that configuration to execute arbitrary Java bytecode under the security context of the PaperCut server process. The result is effectively a pre-authentication remote code execution chain against vulnerable PaperCut Application Servers.

CVE-2026-81578 is the first stage of that chain and is rated 8.8 under CVSS 4.0. It is an improper access control or missing-authentication weakness in the PaperCut NG/MF web-management interface. Under specific conditions, an unauthenticated remote request targeting functionality normally associated with administrative pages can cause backend actions to execute before the application has completed its normal access validation. In practical terms, the attacker can reach operations that developers intended to be restricted to authenticated administrators and modify selected system configuration parameters without possessing a legitimate PaperCut account. The flaw therefore breaks one of the most important trust boundaries in any administrative application: privileged actions must never execute until authentication and authorization have both been successfully completed.

The underlying design lesson from CVE-2026-81578 is more important than the specific HTTP request used to exploit it. Web applications often separate page rendering, component processing and backend actions into several stages. Developers may assume that because a user cannot normally reach an administrative page through the visible interface, the functions behind that page are protected. Attackers do not navigate an application using the menus and buttons developers intended. They construct requests directly and invoke backend components independently. Sensitive operations therefore need to perform authorization at the operation itself rather than relying on the assumption that the caller arrived through an authenticated page. An administrative function that can change security configuration should reject an unauthenticated request before modifying any state, regardless of which front-end component invoked it.

This is also why the vulnerability remains serious even though CVE-2026-81578 alone does not necessarily provide immediate operating-system code execution. Being able to manipulate trusted server configuration is already a powerful capability. Many enterprise applications contain configuration values that determine which classes are loaded, which scripts are executed, which external systems are contacted or which directories are used. If an attacker can alter those values, another apparently legitimate feature may convert configuration access into a much stronger primitive. That is exactly what happens when CVE-2026-81578 is combined with CVE-2026-82078.

CVE-2026-82078 is the second stage and carries a critical 9.4 CVSS 4.0 rating. PaperCut describes it as an unsafe dynamic class-loading vulnerability in its database connection utilities. The application allows database driver class names to be configured and dynamically instantiated, but vulnerable versions do not restrict those class names to a carefully approved allowlist. If an attacker is able to manipulate the relevant configuration, PaperCut can therefore be persuaded to instantiate arbitrary Java classes that already exist on the application classpath. Depending on the class selected and the behavior triggered during loading or initialization, this can result in execution of arbitrary Java bytecode inside the PaperCut Application Server process.

This is essentially an unsafe-reflection problem. Reflection and dynamic class loading are legitimate and extremely powerful features of Java. Applications commonly use them to support plugins, database drivers and configurable components. The security problem appears when attacker-controlled data determines which class is loaded. At that point, the attacker can begin treating the application’s existing classpath as a collection of potential execution gadgets. Instead of uploading a completely new executable, they search for legitimate classes already installed with useful initialization behavior and arrange for the application to instantiate them.

The vulnerability therefore resembles other attack classes involving unsafe deserialization and gadget chains. The attacker is not necessarily breaking Java or bypassing the JVM’s normal execution model. They are abusing legitimate functionality in a context where the developers assumed only trusted administrators could supply class names. Once CVE-2026-81578 breaks that assumption and allows an unauthenticated attacker to modify configuration, CVE-2026-82078 becomes dramatically more dangerous. One vulnerability provides control over trusted application state, and the other converts that state into executable behavior.

This combination is an excellent example of why defenders should analyse exploit chains rather than individual CVEs in isolation. CVE-2026-82078’s CVSS vector includes a high-privilege requirement when considered alone because the attacker would normally need sufficient rights to alter configuration. CVE-2026-81578 removes that prerequisite. When both vulnerabilities are present, the effective attacker requirement changes from highly privileged access to no authentication at all. The combined result is substantially more serious than reading either vulnerability description independently might suggest.

Attackers think exactly this way. They rarely care whether one bug provides complete compromise. A missing authentication check that allows configuration changes may be combined with unsafe reflection, a file-write primitive, command injection or another privileged feature. Security architecture needs to assume that the output of one vulnerability can become the input to another. This is why vulnerability prioritization based exclusively on individual CVSS scores can miss real attack paths.

PaperCut’s response also illustrates how difficult emergency patching can become when the first remediation does not fully address the underlying attack surface. PaperCut initially released an emergency patch after confirming exploitation, but researchers subsequently found additional ways to reach or bypass parts of the mitigation. The company then issued Emergency Patch Release 2 with additional hardening and explicitly instructed customers who had already installed the first emergency update to install Release 2 as well. This is a particularly important operational point because administrators may reasonably believe their systems are protected after completing an emergency patch deployment, only to discover hours later that the vendor’s guidance has changed.

The correct defensive position is therefore not simply “we patched PaperCut on August 28.” Administrators need to verify specifically that Emergency Patch Release 2 is installed. PaperCut has made Release 2 available for versions 24, 25 and 26, and organizations using older versions should move to a supported release. PaperCut NG and PaperCut MF Application Servers, Site Servers and relevant secondary servers need to be included in the inventory rather than updating only the most visible primary server. Print Deploy and Mobility Print are not affected by these specific CVEs, so response should remain technically precise rather than indiscriminately treating every PaperCut component as vulnerable.

The CISA KEV designation should also change how organizations prioritize this work. KEV inclusion does not merely mean a vulnerability is severe. It means CISA has evidence that attackers are actually using it. This is an important difference because defenders are no longer estimating whether exploitation might eventually become attractive. The exploitation threshold has already been crossed. For U.S. Federal Civilian Executive Branch agencies, the vulnerabilities now carry a September 14, 2026 remediation deadline. Private organizations are not legally bound by the same directive, but the technical risk does not care whether the victim belongs to the federal government. Internet-facing PaperCut deployments in schools, universities, enterprises, healthcare environments and service providers should receive equivalent urgency.

PaperCut servers are attractive targets because print-management infrastructure frequently occupies a trusted position inside the network. A PaperCut Application Server may communicate with Active Directory or LDAP, databases, print servers, mail systems and administrative infrastructure. It can contain configuration information, service credentials and detailed knowledge of internal users and devices. Successful code execution on such a server therefore provides an attacker with much more than the ability to interfere with printing. It can create a strategically useful foothold inside the enterprise.

Print servers are also frequently underestimated during security architecture reviews. They may not receive the same attention as domain controllers, VPN gateways or externally facing web applications, yet they often interact with large numbers of internal users and systems. Attackers understand that less glamorous infrastructure can provide excellent persistence and lateral-movement opportunities precisely because defenders may monitor it less aggressively.

The active exploitation observed by Huntress reinforces that concern. Researchers have seen attackers execute reconnaissance commands such as `whoami`, `ver` and `tasklist` after gaining access. These commands may look almost harmless, but their meaning in context is clear. The attacker is determining which identity the PaperCut service runs under, what operating system has been compromised and which processes are available before deciding what to do next. This is classic post-exploitation reconnaissance.

The fact that currently observed activity has included basic reconnaissance should not be interpreted as reassurance that exploitation will remain limited to reconnaissance. Attackers often test newly acquired exploit chains conservatively before deploying more valuable payloads. Once reliable code execution becomes widely understood or public exploit modules appear, the vulnerability can become attractive for ransomware groups, initial-access brokers, botnet operators and state-sponsored actors. PaperCut has already experienced this progression before. CVE-2023-27350 was heavily exploited after disclosure and was eventually associated with ransomware and state-backed activity.

This historical context matters because attackers already understand PaperCut environments. They have previous tooling, reconnaissance knowledge and operational experience targeting the product. A new pre-authentication RCE path therefore does not require adversaries to begin from zero. Some threat actors may only need to substitute a new exploitation technique into an existing operational playbook.

The possibility of public exploit code further reduces the time defenders have available. Once reliable exploitation enters frameworks such as Metasploit or is reproduced in public research, attackers can automate scanning across internet-exposed PaperCut installations. An organization does not need to be specifically targeted. A scanner can identify a vulnerable server, exploit it automatically and hand successful access to another stage of the attack infrastructure.

This is why internet exposure should be addressed independently from patching. PaperCut has advised customers to restrict its web interfaces to trusted IP addresses. If external users do not have a legitimate requirement to reach the Application Server management interface directly from the internet, it should not be publicly accessible. Internal-only access, VPN, ZTNA, administrative proxies or strict source-address restrictions can drastically reduce the population of attackers capable of interacting with the application.

Removing exposure is not a substitute for the patch. Internal attackers, compromised VPN users or malware already inside the network could still exploit a vulnerable instance. But it creates another barrier. If a future zero-day appears before a patch exists, a PaperCut interface reachable only from trusted administrative networks is considerably harder to attack than one indexed by internet scanners.

Network segmentation should continue after the PaperCut server itself. A compromised print-management server should not automatically have unrestricted connectivity to every internal system. Communication should be limited to the directory servers, printers, databases and services genuinely required for operation. Management access to backup systems, virtualization infrastructure and unrelated databases should be blocked unless explicitly necessary.

This becomes particularly important because remote code execution inherits the network position of the compromised server. Attackers do not need the original PaperCut exploit to directly compromise a domain controller if the PaperCut server can simply connect to it afterward. Segmentation determines whether one server compromise remains one server compromise or becomes an enterprise-wide incident.

The security context under which PaperCut runs deserves equal attention. CVE-2026-82078 executes code under the privileges of the PaperCut server process. Organizations should therefore examine which operating-system and domain permissions that service possesses. Running application services using highly privileged domain accounts can transform application RCE into immediate access to unrelated resources. Service identities should have only the permissions necessary for their function and should not be members of administrative groups merely because that was operationally convenient during initial deployment.

Integration credentials need similar scrutiny. PaperCut installations may contain database credentials, directory-integration accounts, mail credentials or secrets used by related services. If a server was potentially compromised before patching, administrators should evaluate whether these credentials were accessible to the PaperCut process and rotate them where appropriate. Patching the vulnerability closes the entry point but does not revoke secrets an attacker may already have copied.

This distinction between vulnerability remediation and compromise remediation is one of the most important lessons from the CISA listing. Installing Emergency Patch Release 2 answers the question, “Can this specific exploit chain still be used?” It does not answer, “Was the server compromised before we patched it?” Any internet-exposed PaperCut instance that remained vulnerable during the active exploitation period should therefore receive at least a compromise assessment.

PaperCut has published several indicators that can assist investigation. Administrators should examine suspicious activity originating from the PaperCut Application Server process, particularly unexpected child processes from `pc-app.exe` on Windows. Missing, unexpectedly truncated or deleted `server.log` files should also be treated as suspicious because attackers may attempt to remove evidence after exploitation. PaperCut additionally identified database-related error messages associated with known activity, although absence of those indicators cannot prove that exploitation did not occur.

That limitation is crucial. Indicators of compromise describe artifacts observed during specific attacks. They are not universal requirements of exploitation. Another attacker may use a different payload, avoid the same error condition or successfully delete logs. Security teams should therefore avoid reducing the investigation to a simple search for two known strings.

Endpoint telemetry should be reviewed for command interpreters, PowerShell, scripting engines or unfamiliar executables launched from the PaperCut process. A print-management application normally has a predictable process tree. It should not suddenly launch operating-system reconnaissance commands, download remote-access tools or create scheduled tasks.

Network telemetry can reveal another part of the attack. PaperCut servers should have reasonably well-defined outbound communication requirements. Connections to newly observed internet infrastructure, unusual long-lived sessions or sudden outbound file transfers deserve attention. Egress filtering can significantly reduce the attacker’s options after successful RCE by preventing the server from freely reaching command-and-control infrastructure.

Centralized logging is especially important because successful code execution may eventually allow an attacker to tamper with local evidence. Application logs, operating-system events, EDR telemetry and relevant firewall records should be forwarded to infrastructure the PaperCut server cannot rewrite. This preserves evidence even if local `server.log` or other records are deleted.

Log retention should cover enough history to reconstruct activity before the vulnerability became public. Zero-day exploitation means attackers may have been active before defenders knew which indicators to search for. If relevant telemetry is retained for only a few days, investigators may discover that the most important evidence has already disappeared.

Authentication logs from neighboring systems should also be reviewed if compromise is suspected. A PaperCut attacker may use the server as a pivot rather than installing obvious persistence locally. Connections from the PaperCut server to file shares, RDP, SMB, WinRM, databases or directory services should be compared with normal behavior.

This is where a vulnerability in a print server becomes an identity-security issue. If administrators previously logged into the server interactively, privileged credentials or authentication tokens may have been exposed. Tiered administration practices are valuable because domain administrators should not routinely log into application servers. A compromise of a lower-tier server should not provide reusable higher-tier credentials.

Organizations should also assess whether PaperCut itself needs to be accessible through the same network interface for users and administrators. Separating management functions from normal user-facing printing workflows can reduce attack surface. Where the product architecture permits, administrative access should come from restricted management networks or privileged workstations rather than the general user network.

The active PaperCut exploitation also demonstrates why vulnerability management needs asset context. CVE-2026-81578 and CVE-2026-82078 should receive extremely high priority on an internet-facing Application Server with directory integration. The same CVEs on an isolated laboratory server without sensitive connectivity still require remediation but present a different immediate risk. Prioritization should therefore combine KEV status, external exposure, business importance and post-exploitation reachability.

CISA’s newer BOD 26-04 approach reflects this risk-based thinking by emphasizing particularly urgent remediation for KEV vulnerabilities on publicly exposed systems that can provide complete asset control. The PaperCut chain is almost a perfect example of why that distinction exists: public exposure combined with pre-authentication RCE provides attackers with direct control of a trusted internal server.

Asset inventory is therefore the first practical requirement. Organizations should identify every PaperCut NG and MF deployment, including production, secondary, Site Server, disaster-recovery, testing and departmental instances. Forgotten servers are especially dangerous because they may remain internet-accessible while receiving little administrative attention.

Non-production servers should not contain production credentials or full production databases wherever possible. A test PaperCut installation may appear low-value until an attacker discovers that it uses the same LDAP bind account or can reach the same domain controllers as production.

Version validation also needs to be exact. Administrators should verify that Emergency Patch Release 2 is actually present rather than relying on the fact that an update job ran. PaperCut’s first emergency patch is not sufficient according to the vendor’s updated guidance. This is one of those rare occasions where the phrase “we installed the emergency patch” is technically ambiguous enough to be dangerous.

Organizations running versions older than 24 should treat the incident as another reason to eliminate unsupported application branches. Legacy software creates a predictable problem during zero-days: even when the vendor responds quickly, the organization may need to perform a major upgrade before it can consume the security fix. Technical debt therefore directly increases incident-response time.

The two vulnerabilities also offer important secure-development lessons. CVE-2026-81578 demonstrates that authentication checks need to be enforced before any backend state transition. CVE-2026-82078 demonstrates that privileged configuration should never be allowed to select arbitrary executable classes. Both failures involve misplaced trust at boundaries between application components.

Allowlisting is particularly appropriate for database drivers because the expected set is inherently limited. If PaperCut supports a known collection of database driver classes, there is little reason to accept an arbitrary Java class name. The application should map a small set of approved identifiers to hard-coded or validated classes. This prevents attackers from treating the entire Java classpath as an execution surface.

The incident also illustrates how the trusted classpath itself becomes part of the attack surface. Java applications commonly contain hundreds or thousands of classes inherited from third-party libraries. Developers may think of these libraries only in terms of the functions their own code directly calls. Unsafe reflection allows an attacker to explore behaviors the application developer never intended to expose.

Dependency minimization can therefore provide defensive value. Fewer unnecessary libraries mean fewer classes available for exploitation and fewer vulnerabilities requiring maintenance. Software composition analysis should not merely identify CVEs in dependencies; teams should also determine whether unused packages can be removed entirely.

The repeated bypass of the initial patch similarly demonstrates the importance of testing security fixes adversarially. A successful patch should not merely stop the original proof of concept. Developers and external researchers should attempt alternate routes toward the same protected functionality. Authentication-bypass fixes need particular scrutiny because complex web frameworks may provide multiple component invocation paths.

Independent security research clearly played an important role here. Huntress and watchTowr reproduced the chain, examined the first remediation and helped identify additional hardening requirements. That collaboration ultimately resulted in Release 2. Vendors should view this external review as part of a mature security process rather than an embarrassment. During an actively exploited zero-day, getting the fix right matters more than pretending the first patch was perfect.

For defenders, the broader lesson is equally useful: emergency vulnerability management needs to remain dynamic. Installing a patch is not a one-time checkbox when the incident is still evolving. Vendor advisories need to be monitored for revised guidance, patch bypasses and updated indicators. The state of knowledge on August 28 can be different from the state of knowledge on August 31.

The CISA KEV listing is precisely such an update. The vulnerabilities were already urgent when PaperCut disclosed confirmed exploitation. KEV inclusion adds authoritative confirmation that these are actively exploited vulnerabilities deserving priority over the enormous backlog of vulnerabilities that merely might be exploited someday.

Organizations frequently face tens of thousands of vulnerability findings. Attempting to patch strictly according to CVSS can leave security teams drowning in critical and high-severity alerts. KEV provides a much more useful prioritization signal because exploitation has moved from theoretical possibility to observed behavior.

However, KEV status should not be interpreted as meaning vulnerabilities outside the catalog are safe. CISA requires credible evidence before adding an entry, and exploitation can occur before public confirmation exists. KEV is therefore a high-confidence priority signal rather than an exhaustive list of everything attackers are using.

The PaperCut incident makes another distinction clear: exploitability and impact are separate questions. CVE-2026-81578 makes privileged configuration reachable. CVE-2026-82078 turns control of that configuration into Java execution. The actual damage afterward depends heavily on how the PaperCut server is deployed. A restricted server with tightly scoped credentials and network access presents a smaller blast radius than a server running under broad privileges on a flat network.

Defense in depth therefore matters even when patching fails. Internet exposure controls reduce who can attempt exploitation. Authentication and authorization protect administrative actions. Safe class loading prevents configuration from becoming execution. Least-privilege service identities limit inherited access. Network segmentation restricts lateral movement. Egress filtering constrains command and control. Endpoint monitoring detects abnormal post-exploitation behavior. Centralized logging preserves evidence. Any individual layer may fail while others still limit the consequence.

That is the central architectural lesson from CVE-2026-81578 and CVE-2026-82078. The attack succeeds because one failed trust boundary feeds another. The authentication boundary fails first, allowing an external attacker to manipulate trusted application configuration. The execution boundary then fails because trusted configuration is allowed to select executable Java classes without sufficient restriction. The combined chain converts an unauthenticated network request into server-side code execution.

For organizations operating PaperCut NG or MF, the immediate actions are therefore clear: identify every affected instance, remove unnecessary public exposure, deploy Emergency Patch Release 2 for supported versions, upgrade older unsupported versions, update relevant Site and secondary servers, verify the installed patch level and perform compromise assessment on systems exposed during the exploitation window. Where suspicious activity is found, investigation should extend beyond the PaperCut application to operating-system activity, credentials, network connections and neighboring systems.

The CISA deadline of September 14 should not be treated as a comfortable two-week patch window for internet-facing systems. It is a compliance deadline for the federal enterprise, not a recommendation that attackers wait politely until September 15. Organizations with publicly reachable vulnerable PaperCut servers should treat remediation as immediate.

The most important takeaway from CISA’s August 31 KEV update is therefore not simply that two more CVE numbers have been added to a catalog. It is that attackers have demonstrated a practical path through two separate trust failures in a widely deployed enterprise application. CVE-2026-81578 defeats the assumption that administrative configuration is available only after authentication. CVE-2026-82078 defeats the assumption that configuration values are safe enough to influence Java class loading.

When those assumptions fail together, an unauthenticated attacker can move from the internet into executable code running inside a trusted print-management server.

That is exactly the sort of chain KEV prioritization is intended to surface, and it is why these two PaperCut vulnerabilities should be treated as an active incident-response concern rather than another pair of entries waiting for the next normal patch cycle.

CISA has added two new vulnerabilities to its Known Exploited Vulnerabilities (KEV) Catalog , based on evidence of active exploitation. CVE-2026-81578 PaperCut NG/MF Missing Authentication for Critical Function Vulnerability CVE-2026-82078 PaperCut NG/MF Unsafe Reflection Vulnerability These types of vulnerabilities are a frequent attack vector for malicious cyber actors and pose significant risks to the federal enterprise. Binding Operational Directive (BOD) 26-04: Prioritizing Security Updates Based on Risk establishes vulnerability management requirements for Federal Civilian Executive Branch (FCEB) agencies. BOD 26-04 reinforces the importance of the KEV Catalog and requires federal agencies to prioritize rapid remediation of high-risk vulnerabilities, specifically those identified by Common Vulnerabilities and Exposures (CVEs) listed in CISA’s KEV Catalog on publicly exposed assets that grant total control of the asset post-exploitation, while deferring action for lower-risk vulnerabilities. BOD 26-04 further establishes basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied. While BOD 26-04 applies only to FCEB agencies, CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities . CISA will continue to add vulnerabilities to the catalog that meet the specified criteria . Aware of an exploited vulnerability not currently listed

Source: CISA Adds Two Known Exploited Vulnerabilities to Catalog via CISA Advisories — published 31 Aug 2026.