SINGAPORE, 30 AUG 2026 — PaperCut published an urgent advisory on 27 August confirming active exploitation of its NG and MF print management software. For about a day the vulnerability had no CVE identifier, no CVSS score and no stated vulnerability class, leaving it invisible to most automated scanning and ticketing tools.
What happened, in order
On 27 August PaperCut said it was investigating active exploitation affecting both products. The advisory carried no CVE, no severity score, no description of the vulnerability class, no statement of whether authentication was required and no technical detail of the exploit path.
Emergency patches followed for versions 25 and 26 at 02:10 AEST on 28 August, with version 24 patched later the same day. Identifiers were then assigned: CVE-2026-81578 and CVE-2026-82078, two vulnerabilities forming a chain.
The vulnerability was found by a customer. A university's security and incident response teams reported what they were seeing, giving PaperCut's own security team enough to reproduce and confirm exploitation in the wild.
Why the missing CVE matters operationally
A modern vulnerability-management programme is keyed to CVE identifiers. Scanners match on them, ticketing systems open work against them, KEV and equivalent catalogues list them, and service-level agreements are written in terms of them.
A confirmed, actively exploited vulnerability with no identifier therefore does not appear in the place where most organisations look. It exists only in the vendor's own advisory, which reaches the people who subscribe to that vendor's bulletins — a much smaller population than the one running the software.
This is not a criticism of PaperCut. Publishing a warning before an identifier exists is the correct call when the alternative is silence during an active attack. But defenders should understand that the industry's alerting machinery has a gap exactly here, and it is widest in the first twenty-four hours, which is when it matters most.
We have watched the same gap before, when GeoServer was probed within hours of a disclosure that had no CVE. Attackers do not wait for an identifier. Detection tooling does.
You cannot triage this by version
Unusually, every released version of both products is affected.
That inverts the ordinary triage question. The usual first move is to establish which versions you run and whether they fall in the vulnerable range. Every version is vulnerable, so the only variable is whether your Application Server is reachable from the internet.
So the inventory question changes shape. Instead of asking what version is installed, ask what is exposed: whether the Application Server has a public address, whether it sits behind a reverse proxy that terminates externally, and whether any convenience rule was added at some point to let staff print from home.
That last one is the common case. Print servers are internal by design and become internet-facing by accretion, usually to solve a problem for one department, and usually years before anyone thinks about it again.
A customer found it, not the vendor
The detection path shows where security signal often originates in practice.
A university's own security and incident response teams saw something, reported it upstream, and gave the vendor enough detail to reproduce and confirm exploitation. The vendor did not find this in a code review or a bug bounty. A customer under attack found it and told them.
That is the ordinary way zero-day exploitation gets discovered, and it depends on two things that cannot be assumed. The customer had to be running detection capable of noticing anomalous behaviour on a print server, which is not where most monitoring budget goes. And they had to report it rather than quietly remediating, which carries no benefit to them and some risk.
Universities are often the source of this kind of discovery. They tend to run large, heterogeneous estates, employ security teams with research inclinations, and have an institutional culture that favours disclosure. Every other PaperCut customer benefited from that this week.
Why print management is a high-value target
PaperCut is deployed heavily in universities, schools, hospitals and government, which is a specific and unfortunate combination.
These are organisations with large user populations, decentralised IT, and print systems that are integrated with directory services in order to authenticate users at the device. A print management server frequently holds or brokers credentials, sits inside the network with broad reach, and is administered by a team whose primary responsibility is not security.
The category has been targeted before for exactly these reasons, and the pattern of a specialised administrative application being the entry point into an otherwise well-defended estate is now familiar. Ransomware operators are not interested in printing. They are interested in a server that talks to everything and is patched on a slower cycle than the domain controllers.
What to do
Patch immediately. Versions 25 and 26 have fixes, as does version 24, and every released version is affected so there is no version at which you can wait.
Then determine internet exposure and remove it if it exists, because that is the discriminator between an urgent problem and a routine one. If external access is genuinely required, put it behind a VPN or an authenticating proxy rather than exposing the Application Server directly.
Assume compromise if you were exposed before patching, and look for it rather than concluding it. Exploitation was confirmed in the wild before the patch existed. Whether you were affected during that window is a question for your logs, not for your patch status.
And check whether your vulnerability-management process can ingest a vendor advisory that carries no CVE. If your process cannot ingest a vendor advisory without a CVE, this incident is the argument for fixing that.
View author profile → · Editorial policy
