Cybersecurity News
Cybersecurity News: PaperCut Zero-Day Under Attack
Published August 28, 2026 · DNS Benchmark Pro Editorial · Reading time: 5 minutes
TL;DR — The most urgent cybersecurity news of the week is a zero-day vulnerability in PaperCut NG and PaperCut MF, the print management platform used across universities, hospitals, law firms and local government. On Thursday 27 August 2026 PaperCut Software published an urgent advisory confirming active exploitation against real customers, affecting all versions of both products. Emergency out-of-cycle builds for the v25 and v26 branches followed in the early hours of 28 August AEST, covering Windows, Linux and macOS. No CVE identifier has been assigned yet. Administrators should treat any internet-exposed PaperCut Application Server as hostile until proven otherwise: patch, restrict the web interface to trusted IP ranges, and hunt for the published indicators of compromise.
This is the kind of cybersecurity news that ruins a Friday change freeze. PaperCut's security response team did not wait for a CVE, a CVSS score or a coordinated disclosure window. It published while the investigation was still open, because customers were already being hit. "We are aware of confirmed customer incidents and are treating this matter with the highest priority," the advisory reads — language vendors reserve for the moment telemetry stops being theoretical.
The initial report did not come from a bug bounty or a red team. It came from a university customer whose internal security and digital forensics teams found something wrong on their own print server and handed the evidence to the vendor. PaperCut engineers used that material to reproduce the flaw and confirm exploitation in the wild. That detail matters: this was discovered downstream, in production, after attackers had already found it.
What the zero-day vulnerability actually does
PaperCut has been deliberately sparing with technical detail while patches propagate, which is the correct call. What is public is enough to size the risk. The flaw gives an unauthenticated attacker remote control over PaperCut's trusted configuration, and from there the ability to execute arbitrary Java code inside the application server process.
The mechanism is an authorisation-context confusion bug. In unpatched builds, a specially crafted request can name one page to be rendered in the response while a different page owns the component or action that actually executes. The authorisation check evaluates permissions for the page being rendered, not for the component behind it — so the check passes for a harmless view while a privileged action fires underneath. Chain that into configuration writes, reach a sensitive endpoint that performs an unsafe operation, and you have pre-authentication remote code execution.
Note what this class of bug does not require: no memory corruption, no heap grooming, no per-target exploit tuning. Like the improper access control flaws that have dominated edge-device compromises for the last three years, it is reachable with correctly shaped HTTP. That is precisely why it automates well and why internet-wide scanning follows disclosure within hours.
Why a print server is a high-value target
| Property | Detail | Consequence for server infrastructure |
|---|---|---|
| Affected versions | All PaperCut NG and MF releases | No safe baseline; version triage does not reduce scope |
| Authentication required | None | Pre-auth; no phishing or credential step in the chain |
| Impact | Arbitrary Java code in the app process | Full host control at the service account's privilege level |
| Typical placement | Internal server, frequently internet-exposed for remote print | Bridges the perimeter directly into a trusted VLAN |
| Directory integration | Commonly synced to AD / LDAP | Read access to user identity data and service credentials |
Print management is the classic under-governed tier. It is not a crown-jewel application, so it rarely gets crown-jewel scrutiny, yet a PaperCut Application Server usually holds a directory service account, sits deep inside the corporate network, and — because staff want to print from home — is very often published to the internet. It is a pivot point wearing the costume of a utility.
Indicators of compromise administrators should hunt now
PaperCut published a preliminary IOC set alongside the advisory, with the honest caveat that absence of indicators does not mean absence of compromise. Treat these as hunting leads, not a clean bill of health:
- Anomalous behaviour from
pc-app.exe. The process itself is legitimate. What is not legitimate is it spawning shells, writing outside its normal paths, or opening outbound connections it has never made before. - Missing, truncated or modified
server.logfiles. Log tampering is post-exploitation housekeeping. A gap in the log is itself a finding. - Specific database errors in
server.log:ERROR No suitable driver found for jdbc:no:xandERROR DatabaseUtils - Database error looking up cardID: VALUES CAST. Both are artefacts of injected configuration values being evaluated by the application.
PaperCut has not disclosed attribution, post-exploitation objectives, or whether data is being exfiltrated. The investigation is ongoing and the advisory is being updated as findings land.
Immediate actions for IT security teams
- Apply the emergency build. Out-of-cycle releases exist for both the v25 and v26 branches across Windows, Linux and macOS. There is no configuration-only workaround that preserves normal function.
- Restrict the web interface at the network layer. Firewall rules or network access controls limiting the Application Server's web UI to trusted IP ranges are the highest-value control available, and they hold even if a variant of this bug surfaces later. PaperCut names this as its primary mitigation.
- Assume exposure equals compromise. If the server was internet-reachable before 27 August, patching is not remediation. Rotate the directory service account, review outbound connections from the host, and inspect the print archive if the feature is enabled.
- Check egress, not just ingress. A pre-auth RCE on an internal server is only valuable to an attacker if the host can call home. Most print servers have no business making arbitrary outbound requests.
The DNS security angle on post-exploitation
It is easy to file this under application security and stop. That misses the detection opportunity. Every plausible post-exploitation step here depends on name resolution: a loader resolves a command-and-control hostname, a second stage resolves a staging host, and exfiltration resolves wherever the data is going. Recursive DNS is one of very few chokepoints that observes all of it — and on a print server, where endpoint agents are frequently absent by policy or because the vendor discourages them, it may be the only observation point you have.
Concrete DNS security controls that apply directly: route server-VLAN resolution through a logged, filtered recursive resolver rather than an ISP default; alert on newly registered domains and on any DNS over HTTPS request originating from a server subnet, because a DoH-capable implant will happily route around a resolver that only inspects port 53; and retain query logs long enough to answer "when did this host first look that up?" during forensics. Our primer on DNS over HTTPS covers that visibility trade-off in detail. None of this substitutes for patching. It compresses the interval between compromise and detection, which is the number that decides whether an event becomes an incident or a data breach update.
There is a performance dimension too. Organisations that funnel all outbound resolution through a single filtering resolver sometimes discover mid-incident that the resolver is a single point of failure with mediocre DNS server performance under load — or that it degrades badly when a DDoS attack or a mass-patching event drives query volume up. Measuring resolver latency before you depend on it is unglamorous work that pays out exactly once, at the worst possible moment.
Why PaperCut, again
This is not the platform's first emergency. In April 2023, attackers began mass-exploiting CVE-2023-27350, an authentication bypass leading to remote code execution. Microsoft subsequently attributed a portion of that activity to the Clop ransomware operation, which used vulnerable PaperCut servers as an initial access vector rather than as a document-theft target, and observed separate intrusions ending in LockBit deployments. Iranian state-aligned groups joined the campaign. By May 2023, CISA and the FBI had issued a joint advisory warning that the Bl00dy ransomware gang was hitting education-sector PaperCut servers specifically.
The pattern repeats because the economics are good, which is why PaperCut keeps returning to the cybersecurity news cycle. One widely deployed product, thousands of internet-exposed instances, a homogeneous install base, and defenders who classify it as low-priority infrastructure. Ransomware affiliates do not need a novel intrusion technique when a print server hands them a domain-joined foothold.
The education sector is again the obvious exposure. Universities run large PaperCut estates for student printing, publish them for off-campus access, and operate under change control that is optimised for semester schedules rather than same-day emergency patching. That a university's own forensics team found this one is fitting — and a reminder that the sector's security maturity is frequently better than its patch velocity is allowed to be.
What this means for enterprise IT
Three lessons in this cybersecurity news cycle carry well beyond PaperCut. First, the perimeter is now made of middleware and business utilities — print servers, file transfer appliances, VPN concentrators, proxy tiers. These are internet-facing, they hold implicit trust, and they patch on a slower cycle than the applications behind them. Cloud security and asset inventory programmes that catalogue workloads but not the plumbing between them will keep missing this class of exposure.
Second, "all versions affected" defeats version-based triage. There is no safe release to fall back to, no supported-branch argument to make. The only variables that reduce risk are patch state and network exposure — which means an accurate answer to "what of ours is reachable from the internet?" is worth more than any scanner report.
Third, vendor advisories are increasingly arriving before CVE assignment. A vulnerability management programme that only ingests CVE feeds will not see this one until the identifier lands, potentially days from now. Monitoring vendor security bulletins directly for the products you actually run is no longer optional hygiene; it is the difference between patching on day zero and patching on day four.
If you run PaperCut and cannot say today whether your Application Server is reachable from the public internet, that is the first question to answer — before the patch, before the log review, before anything else. A quick DNS and reachability benchmark from outside your network is a reasonable place to start.
Sources: PaperCut Software urgent security advisory (27 August 2026) and subsequent emergency build notices; BleepingComputer reporting by Lawrence Abrams (27 August 2026); Help Net Security (27 August 2026); Huntress technical analysis; historical context from CISA/FBI joint advisory AA23-131A and Microsoft Threat Intelligence reporting on CVE-2023-27350. This article is independent editorial analysis and is not affiliated with or endorsed by PaperCut Software.