The active exploitation of an undisclosed vulnerability affecting every version of PaperCut NG and PaperCut MF deserves immediate attention because this is not a theoretical vulnerability announcement or a proof-of-concept published ahead of exploitation. PaperCut has confirmed real customer incidents and has reproduced the vulnerability using information supplied by a university customer and its incident-response team. At the time of the advisory, PaperCut had not publicly disclosed the technical details of the flaw, the exact exploitation mechanism, or the identity of the attackers. That lack of detail should not be interpreted as reduced urgency. In fact, when a vendor confirms active exploitation before full technical disclosure, defenders have less information available while attackers already appear to understand how to exploit the weakness. That asymmetry is precisely what makes a genuine zero-day situation dangerous.

The most important immediate fact is that all versions of PaperCut NG and PaperCut MF are potentially affected. This means organizations cannot safely determine exposure simply by checking whether they are running a reasonably recent release. PaperCut’s urgent guidance is specifically directed at organizations whose PaperCut Application Servers are accessible from the public internet: restrict access to the web interfaces immediately so that only trusted IP addresses can reach them. Firewall rules, network access controls or equivalent mechanisms should be used even when administrators have not observed any suspicious behavior. This is a sensible emergency containment measure because the attack surface can be reduced before complete details of the vulnerability are available.

The PaperCut Application Server is particularly important because it serves as the central component of both NG and MF deployments. Print-management systems are often treated as relatively mundane infrastructure, but they can have extensive access to enterprise resources. They may integrate with Active Directory or LDAP, maintain user and group information, communicate with print servers and multifunction devices, store administrative credentials, maintain databases and, depending on configuration, retain information relating to print jobs. Compromising such a server can therefore provide attackers with considerably more value than simply disrupting someone's ability to print a quarterly report, which admittedly might be considered a public service in some offices.

The fact that PaperCut is specifically warning about internet-exposed Application Servers suggests that reducing direct public exposure should be the first defensive priority. Even before the vulnerability is fully understood, organizations should ask a fundamental architecture question: why does the PaperCut administrative or application interface need to be accessible from arbitrary internet addresses in the first place? Administrative systems should generally be reachable only from trusted management networks, VPN-connected administrators, approved jump hosts or explicitly authorized IP ranges. An application can be fully patched today and vulnerable tomorrow, but removing unnecessary internet exposure provides protection against entire classes of future vulnerabilities rather than only the one currently making headlines.

This is particularly relevant in PaperCut's case because the platform has already attracted substantial attacker attention in the past. In 2023, attackers exploited CVE-2023-27350, an authentication-bypass vulnerability that could lead to remote code execution, together with CVE-2023-27351, an information-disclosure issue. Those attacks were subsequently associated with several different threat actors, including ransomware operations such as Clop and LockBit, while Iranian state-linked groups were also observed exploiting vulnerable PaperCut servers. The historical lesson is important: once a reliable exploitation technique against widely deployed enterprise infrastructure becomes available, exploitation does not necessarily remain confined to one threat group. Techniques and exploits can spread rapidly across the criminal ecosystem.

The current zero-day should therefore be viewed as a potential initial-access vulnerability until proven otherwise. PaperCut has not yet disclosed what attackers are doing after exploitation, so it would be premature to claim that the flaw directly provides remote code execution or that ransomware deployment has occurred in the current incidents. However, the vendor has specifically advised organizations to investigate suspicious post-exploitation activity originating from the legitimate `pc-app.exe` process. That indicator suggests defenders should pay close attention not only to requests reaching the PaperCut web interface but also to what the PaperCut process subsequently does on the operating system.

The reference to `pc-app.exe` is particularly useful from a detection perspective. Attackers frequently abuse trusted application processes after gaining access because those processes already possess legitimate permissions and network access. Security teams should therefore investigate unusual child processes spawned by `pc-app.exe`, unexpected command-shell or scripting execution, abnormal outbound network connections, suspicious file creation and interactions with credential stores or other sensitive operating-system resources. A process having a legitimate filename does not make every action performed by that process legitimate. Process lineage and behavior matter considerably more than filenames alone.

PaperCut has also identified several log-related indicators that administrators should examine. Missing, unexpectedly truncated or deleted `server.log` files may indicate that an attacker attempted to remove evidence. Two specific error messages have also been highlighted: `ERROR No suitable driver found for jdbc:no:x` and `ERROR DatabaseUtils - Database error looking up cardID: VALUES CAST`. These entries may be associated with exploitation attempts or related attacker activity and should therefore be searched across current and historical PaperCut logs.

At the same time, PaperCut explicitly warns that the absence of these indicators does not confirm that a system is clean. This qualification is extremely important. Indicators of compromise are usually observations associated with known incidents, not mathematical proofs of infection. Attackers may use slightly different payloads, clean logs successfully, exploit the vulnerability through another variation or simply avoid generating the exact indicators currently known to the vendor. Organizations should therefore avoid performing two log searches, finding nothing and declaring victory. That would be an unusually efficient way of converting incomplete threat intelligence into misplaced confidence.

The possibility of deleted or truncated logs also highlights why centralized logging is essential for important application servers. If the only copy of a server's activity logs remains on the server itself, an attacker who compromises that host may be able to modify or delete the evidence needed for investigation. PaperCut logs, operating-system logs, authentication events, firewall activity and EDR telemetry should ideally be forwarded to external logging infrastructure that the PaperCut server cannot modify. This permits investigators to reconstruct activity even when local evidence has been tampered with.

Organizations should also retain relevant network telemetry. DNS queries, proxy logs, firewall sessions and flow records can help identify suspicious outbound communication after exploitation. If `pc-app.exe` or another process on a PaperCut server suddenly begins communicating with unfamiliar internet infrastructure, downloading executable content or transferring substantial amounts of data, those events deserve immediate investigation. Even without knowing the exploit itself, post-exploitation behavior often provides enough information to identify compromise.

The emergency nature of the advisory also highlights an important vulnerability-management principle: compensating controls can sometimes be more valuable than waiting for a perfect patching process. If public exposure can be removed immediately by changing firewall policy, there is little reason to leave the service exposed while administrators schedule an application upgrade for some ceremonially approved maintenance window three weeks away. Reducing exposure can happen independently of patch deployment and dramatically decrease the opportunity for exploitation.

PaperCut has also released emergency patches for customers operating public-facing PaperCut NG/MF servers who cannot immediately implement other mitigating controls. Organizations should apply the vendor-provided remediation appropriate to their deployment while continuing to restrict exposure wherever possible. Patching and network restriction should not be viewed as mutually exclusive choices. A patched administrative system that remains unnecessarily exposed to the entire internet is still architecturally weaker than a patched system available only through controlled administrative paths.

Administrators should also remember that patching a system after exploitation does not remove an attacker who has already established persistence. Once a host may have been compromised, remediation becomes an incident-response problem rather than simply a patch-management problem. Security teams should determine whether unauthorized accounts were created, services modified, scheduled tasks added, binaries replaced, startup mechanisms altered or remote-access tools installed. If suspicious activity is identified, rebuilding from a trusted source may provide greater confidence than attempting to clean an unknown compromise in place.

Credential exposure should form part of that investigation. A PaperCut server may contain service-account credentials, directory-integration secrets, database credentials, certificates or authentication information used to communicate with other systems. If attackers achieved operating-system-level access, defenders should assume that credentials accessible to the compromised host may also have been exposed until investigation establishes otherwise. Relevant passwords, tokens, keys and certificates may need to be rotated as part of recovery.

Network segmentation can significantly reduce the consequences of such compromise. The PaperCut Application Server should communicate only with systems and services genuinely necessary for printing and administration. It should not automatically have unrestricted connectivity to domain controllers, unrelated application servers, database networks or management infrastructure simply because everything exists inside the corporate network. If exploitation occurs, segmentation can prevent a vulnerable print server from becoming an effortless launchpad for lateral movement.

This becomes especially important because print infrastructure frequently sits in an awkward security position. It needs to communicate with many endpoints and printers, but it is rarely treated with the same security priority as identity infrastructure or externally facing web applications. That combination can make print-management servers attractive stepping stones. Attackers are perfectly happy to compromise whichever system provides the easiest route toward their objective. They have no obligation to begin with the technology the security department considers strategically important.

Outbound access should therefore be reviewed as well. A PaperCut server generally has predictable connectivity requirements. It may need access to printers, directory services, databases, licensing infrastructure or specific vendor services, but unrestricted outbound internet access is rarely necessary. Egress filtering can prevent a compromised server from freely contacting arbitrary command-and-control infrastructure or downloading secondary payloads. Even when complete blocking is impractical, monitoring unusual destinations can produce strong detection signals.

Another useful defensive measure is application-aware monitoring. Simply knowing that the PaperCut server communicated over TCP port 443 provides limited security value because malware can also use HTTPS. Security teams should determine which destinations are normal for the server, which processes initiate those communications and whether data-transfer patterns are consistent with expected behavior. Behavioral baselining becomes particularly useful during zero-day situations because defenders may not yet have vulnerability-specific signatures.

The current incident also illustrates why threat hunting should begin before full technical disclosure. Organizations sometimes wait for a CVE identifier, proof-of-concept exploit, IDS signature and detailed vendor advisory before investigating. By then, attackers may have enjoyed several days of uninterrupted activity. When a vendor has already confirmed customer exploitation, defenders possess enough information to start hunting based on affected assets, process behavior, logs and network anomalies.

Asset inventory becomes essential here. Security teams should be able to determine quickly where PaperCut NG or MF is deployed, which versions are installed, which servers are internet-facing and which internal systems those servers can reach. If answering those questions requires manually asking dozens of business units whether they happen to run PaperCut, the organization has discovered an asset-management problem at precisely the least convenient moment.

The “all versions affected” statement should also encourage organizations to review shadow or forgotten deployments. Universities, schools and large enterprises may operate multiple PaperCut instances maintained by different departments or campuses. A central IT team may patch the primary server while an independently managed departmental instance remains exposed. Attackers scanning the internet do not care which department forgot to update the asset register.

Education environments deserve particular attention because PaperCut is widely used in universities and schools, and the current investigation reportedly benefited from information supplied by a university customer's security team. Educational institutions often combine large numbers of users, decentralized administration, open networks, legacy infrastructure and limited security staffing, creating conditions that attackers routinely exploit. Print-management servers within these environments should therefore receive the same exposure review and monitoring applied to other internet-facing enterprise services.

The current situation also provides an excellent example of coordinated vulnerability response working as intended. A customer security team and digital-forensics responders supplied information that enabled PaperCut to reproduce the vulnerability, after which the vendor initiated an emergency engineering response and began issuing mitigation guidance. Rapid information sharing between affected organizations, researchers and vendors can substantially reduce the time required to understand a new attack. During an active zero-day campaign, hours matter.

At the same time, responsible disclosure creates an unavoidable tension. Defenders naturally want precise technical details immediately, while publishing exploit information too early may help additional attackers weaponize the vulnerability before customers have deployed protections. PaperCut's decision to initially provide defensive indicators and exposure-reduction guidance without explaining the vulnerability in detail is therefore understandable while emergency remediation is underway. The goal during the earliest stage should be to reduce attack surface rather than satisfy everyone's curiosity about exactly which line of code betrayed humanity this week.

The earlier exploitation of PaperCut vulnerabilities in 2023 should also influence incident-response assumptions. CVE-2023-27350 was not exploited by only one category of attacker. Ransomware groups, cybercriminals and state-linked actors all demonstrated interest in vulnerable PaperCut systems. If technical details of the current vulnerability become public, organizations should expect scanning and exploitation attempts to expand rapidly rather than assuming the activity will remain limited to whoever discovered the zero-day first.

This creates a narrowing defensive window. Before public technical disclosure, a smaller number of actors may possess working exploitation knowledge. Once reverse engineering, proof-of-concept code or detailed analysis becomes available, that knowledge can spread quickly. Organizations operating exposed servers therefore gain substantial security benefit by mitigating now rather than waiting until exploitation becomes easier for everyone.

The situation also reinforces why administrative interfaces should generally not be exposed directly to the internet. This principle applies far beyond PaperCut. Firewalls, VPN concentrators, virtualization platforms, backup systems, monitoring platforms and management servers routinely become attractive targets because successful compromise can provide privileged access to the rest of the environment. Access should instead be mediated through VPNs, ZTNA systems, dedicated management networks or bastion hosts with strong authentication and monitoring.

Multi-factor authentication remains useful but should not be treated as sufficient protection against an unknown application vulnerability. If an attacker can exploit a flaw before authentication or bypass application authorization entirely, MFA may never enter the attack path. This is another reason zero trust cannot be reduced to identity verification alone. Network exposure, application behavior, least privilege and segmentation remain essential even when strong authentication is present.

Organizations should also revisit their incident-response playbooks for infrastructure applications such as PaperCut. The response procedure should clearly define who can restrict internet access, who owns the application, where logs are stored, what credentials need rotation and how the service can be rebuilt. During an active attack, discovering that firewall changes require three approval committees and the only employee who understands the print server is on holiday is not an especially elegant security control.

From a detection-engineering perspective, defenders can create temporary high-priority rules around PaperCut Application Servers. Alerts involving `pc-app.exe`, unexpected child processes, new executable files, command interpreters, unusual outbound connections and log deletion should receive elevated severity. Network controls can similarly alert on connections to the PaperCut web interfaces from unapproved sources. These measures may produce some additional noise, but during confirmed active exploitation the risk calculation changes substantially.

Monitoring for log manipulation deserves particular emphasis. Attackers who delete or truncate logs are demonstrating intent to conceal activity, which is substantially more suspicious than ordinary application errors. Security tooling should alert when application logs disappear unexpectedly, shrink significantly or stop updating while the service continues running. File-integrity monitoring can provide useful visibility into these changes.

Security teams should also consider the possibility that attackers deliberately manipulate the logs specifically because defenders have begun searching for known indicators. Once an IOC becomes public, sophisticated attackers may adapt. Behavioral detections therefore remain more durable than searching exclusively for exact strings. The two PaperCut error messages are useful starting points, but they should not become the entire detection strategy.

The current vulnerability is also a useful reminder that CVE numbers arrive after reality sometimes does. At the time of initial reporting, PaperCut had not publicly provided a CVE identifier or detailed technical classification for the vulnerability. Nevertheless, exploitation was already occurring. Vulnerability-management systems that only react when a CVE appears in a scanner feed can therefore lag behind real-world threats. Security teams need mechanisms for handling vendor emergency advisories and threat intelligence independently of traditional CVE workflows.

Risk prioritization should consequently include exploitation evidence as a major factor. A vulnerability with incomplete technical details but confirmed active exploitation against an organization's exposed product can represent greater immediate risk than dozens of formally scored critical CVEs affecting unreachable systems. Security operations should prioritize based on attackability and exposure, not merely the number printed beside CVSS.

The incident also demonstrates why internet exposure management is becoming as important as vulnerability scanning. Organizations should continuously identify which services are externally reachable and compare that exposure against intended architecture. A forgotten PaperCut server inadvertently exposed by a firewall change may not generate a vulnerability alert if it is fully patched today, but it still creates unnecessary future risk. External attack-surface monitoring can detect these architectural mistakes before a zero-day turns them into incidents.

For organizations that cannot immediately upgrade or restrict the server sufficiently, additional temporary controls may help reduce risk, such as allowing access only through a VPN, placing the server behind a reverse proxy with strict source restrictions, disabling unnecessary public interfaces, increasing EDR monitoring and preventing the server from initiating arbitrary outbound connections. These measures should complement rather than replace vendor remediation.

The broader lesson from this PaperCut zero-day is that defenders should design systems assuming applications will occasionally contain unknown vulnerabilities. Nobody can patch a vulnerability before it is known, but organizations can still control whether the vulnerable service is exposed to the entire internet, what privileges it possesses, which systems it can reach, what outbound connections it can establish and whether suspicious behavior will be detected. Those architectural controls determine whether a zero-day becomes a contained server incident or the beginning of a network-wide compromise.

This is where defense in depth proves its value. If internet exposure is restricted, many attackers never reach the vulnerable interface. If exploitation nevertheless occurs from a trusted network, least privilege limits what the PaperCut process can do. If privilege controls fail, segmentation restricts lateral movement. If lateral movement is attempted, EDR and network monitoring create detection opportunities. If credentials are stolen, MFA and privileged-access controls may prevent their reuse. Security works best when no single vulnerability is permitted to become the entire security architecture's final exam.

Most importantly, organizations running PaperCut NG or MF should treat the current situation as both a vulnerability-management and compromise-assessment event. Restricting public access and applying the emergency remediation address future exploitation attempts, while reviewing logs, endpoint behavior and network activity helps answer the equally important question of whether exploitation has already occurred. Those are separate tasks, and completing only the first leaves half the problem unanswered.

The current PaperCut incident ultimately demonstrates the uncomfortable reality of zero-day defense: there will always be periods when attackers understand a vulnerability better than defenders do. Organizations cannot eliminate that possibility, but they can dramatically reduce its consequences. Removing unnecessary public exposure, enforcing least privilege, controlling outbound traffic, segmenting critical systems, centralizing logs and maintaining strong behavioral detection all continue working even when the vulnerability itself has no published CVE, no signature and no detailed explanation. That is the difference between building security around patches and building an architecture capable of surviving the vulnerabilities nobody has patched yet.

PaperCut is warning that hackers are actively exploiting a vulnerability in all versions of its PaperCut NG and PaperCut MF print management software in zero-day attacks. [...]

Source: PaperCut warns of NG, MF flaw exploited in zero-day attacks via Bleeping Computer — published 27 Aug 2026.