PaperCut: the print server runs as SYSTEM, and nearly half the measured estate has no patch

Every building has a front door with a reception desk, and a service door where the boxes come in and the rubbish goes out. The first one has a camera, a visitor log and somebody watching. The second one sits propped open half the morning because that is convenient. On a corporate network, the service door is usually the print server: it is not on the critical systems list, nobody has touched it in two years, and it works. This week it was, once again, the way in.

On 27 August, PaperCut published an urgent advisory for all PaperCut NG and PaperCut MF customers: it was investigating active exploitation and had confirmed customer incidents. The identifiers arrived the next day. CVE-2026-81578, improper access control in the web management interface, CVSS 8.8. CVE-2026-82078, unsafe dynamic class loading in the database connection utilities, CVSS 9.4. Chained together, they give unauthenticated remote code execution inside the Application Server process.

So far, the story you have already read elsewhere, and it always ends the same way: patch now. We want to stop at two things that appear only in passing in the coverage and that, for an ordinary company, are what actually decide the outcome. One is which account that service runs under. The other is that almost half of the installations anyone has been able to count have no patch to apply at all.

Three days, in order

The timeline matters because it shows who was ahead, and it is worth reading with the clocks in mind: PaperCut is a Melbourne company and dates its updates in Australian time. Huntress observed exploitation activity in customer environments on 26 and 27 August. The bulletin went out on the 27th. The first emergency patch shipped at 02:10 AEST on the 28th — six ten in the evening of Thursday the 27th in Spain — and covered only the 25 and 26 branches. The two CVEs were assigned on Friday the 28th. In other words: the flaw was being used before the advisory existed, which is the definition of a zero-day rather than a dramatic way of putting it.

The scale, on the other hand, is more modest than the noise suggests: Huntress describes limited activity in two customer environments, and puts one of the incidents at under two minutes in total. That figure is not the duration of an attack against a company; it is the duration of the part you can see. There is another detail in the bulletin that reads fast and says a lot: PaperCut explains it was able to reproduce the flaw thanks to information handed over by a university customer's security team and its digital forensics and incident response team. What found this was not a scanner: it was somebody looking at their own incident.

The word that changes the size of the problem: SYSTEM

The chain, as Huntress describes it, has two steps and neither is exotic. First, a request crafted so that it references one page for rendering while executing actions from another: that skips the authorisation check on the management interface. Second, the database connection utilities are abused to load arbitrary Java bytecode. The first flaw opens the door and the second one walks the code in.

What came next is textbook routine: base64-encoded discovery commands — whoami & ver, then whoami & ver & tasklist —, .class files dropped on the server, output written to a file, and logs and payloads deleted afterwards. The detail that made us look up is not in those intrusions but in the proof of concept Huntress rebuilt in its lab: from a remote host they managed to spawn an observable process, charmap.exe, hanging off pc-app.exe and running as SYSTEM. Whatever an attacker executes in there runs at that level.

The 47%: for almost half of them, "patch now" means nothing

Huntress published, almost in passing, the figure that orders everything else. It has visibility over roughly 2,500 PaperCut installations and says 47% of them are running version 23 or older. That is their telemetry, not a global census, but it is the only real number on the table. For that branch there is no patch, and the vendor says so plainly in its FAQ: "the recommended path for all customers prior to PaperCut NG/MF v24 is to upgrade to the latest version".

That sentence, said on a Friday with active exploitation under way, describes a project rather than a task. Applying an emergency patch is a short maintenance window and a service restart. Jumping a major version on a corporate print system is something else: checking driver compatibility, the directory integration, user cards, the embedded applications on each brand of multifunction device, and a test before touching production. The work facing that 47% does not fit into a Friday afternoon. And the uncomfortable part is that the work did not appear now: it had been left undone for years, and what changed is that today it has a deadline.

This is our reading, and we flag it as a reading: that 47% is not negligence, it is what happens when a server has no clear owner. The print server usually falls into no-man's-land between whoever administers the systems and whoever manages the photocopier contract. It is not that somebody decided not to upgrade it; it is that it never appeared on any list where such a decision would be made. The same thing we wrote about the remote management agent your provider installs: software that arrives through a channel other than IT inherits nobody's lifecycle.

Thursday's patch did not hold on Friday

At 20:42 AEST on the 28th — midday on Friday in Spain — PaperCut shipped a second round of emergency patches, Emergency Patch Release 2, after working with its internal team and with researchers from Huntress and watchTowr who had found multiple bypasses of the original patches, plus an additional authentication bypass flaw. The 24 branch, left out of the first patch, did not get its own until an hour and a half later. The vendor puts it plainly: install Release 2 even if you have already applied the original emergency patch. Anyone who patched diligently on Thursday evening was still exposed on Friday.

This is not a complaint about the vendor: shipping two rounds in under a day, with external researchers breathing down your neck, is doing it well. It is a complaint about how the rest of us organise ourselves. A patch is not an event, it is a state. If your process consists of applying the patch and closing the ticket, your company's exposure window is set by the day you happened to pass through, not by the actual state of the software. The standard we argue for is the opposite: a patch is not closed until somebody re-checks the installed version against the advisory as it stands today, not as it stood when you read it.

And there is a practical corollary: if the patch can be bypassed, the network mitigation is the one that holds both times. It is worth underlining who says so, because it is not our idea: PaperCut itself puts this in a section headed Immediate action required, ahead of the patch section, in language that leaves no room for a lukewarm reading: "take this action now, even if you have not observed suspicious activity". Restrict the server's web access to trusted addresses — internal ranges — using firewall rules or network access controls. Rapid7 says the same, and Huntress adds the VPN plus a question you should answer in writing: review why any PaperCut management interface is reachable from the internet. When an advisory like this lands, you close the access first and patch second.

This already happened in 2023, with the same product

On 11 May 2023, CISA and the FBI published a joint advisory titled, literally, Malicious Actors Exploit CVE-2023-27350 in PaperCut MF and NG. That flaw was remote code execution without credentials, CVSS 9.8. The FBI observed exploitation from mid-April and, by early May, a group calling itself the Bl00dy Ransomware Gang was using it against the Education Facilities Subsector. The sentence that closes the circle is in the advisory itself: they got into networks where vulnerable PaperCut servers were exposed to the internet. Some of those operations ended in data exfiltration and encryption.

Three years on: different CVE, different chain, same product and — this is the part that stings — the same prerequisite. What has not changed in three years is not the software. It is that this server still has nobody who wakes up on a Tuesday thinking about it.

What to check this afternoon, in this order

If you run PaperCut NG or MF, this is one afternoon and needs no project:

• Can it be reached from outside? This is the first question and the only one you can answer without touching the server. If the management interface answers from the internet, close it to internal ranges or the VPN right now. This holds whether you have patched or not, and it would have held in 2023 too.
• Which exact version are you on? Not "the last one we installed" — the number. If it is 24, 25 or 26 there is an emergency patch, and it has to be the second round. Careful here, because it is easy to get wrong: the build numbers circulating for the 25 branch on Windows — 25.0.12.76497 (NG) and 25.0.12.76496 (MF) — are the first patch, not Release 2. For the second round PaperCut publishes no build number, only the SHA256 of each installer in the bulletin itself: verify against that hash, not against a version number. If you are on 23 or older there is no patch: you have to plan the version jump, and until then the previous point is your only real control.
• And the other servers? The primary Application Server is not enough. PaperCut says Site Servers and secondary or print servers must also be brought to a patched version. Print Deploy and Mobility Print, on the other hand, are not affected and need no action; on the latter the vendor is explicit down to the ports: Mobility Print runs on a separate, unaffected architecture and is not impacted, so you can leave Mobility Print ports open. Knowing what NOT to touch saves as much time as knowing what to touch.
• Which account does the service run under? Look it up in the Windows services list, do not assume. If it is SYSTEM, you now know what a code execution flaw in there is worth. Dropping privileges on a print server is not always trivial, but at least make it a decision somebody took, rather than a box that came ticked from the installer.
• Look for the traces before you restart anything. The indicators Huntress published are very concrete: the string DB URL: jdbc:derby:memory:pwn in server.log; entries with irregular database names in /data/internal/derby.log; unexpected .class files in the server/lib/ directory; a missing or truncated server.log; the errors No suitable driver found for jdbc:no:x and DatabaseUtils - Database error looking up cardID: VALUES CAST; and any shell or discovery utility spawned as a child of pc-app.exe. And here is a warning that is in no coverage today: this very morning PaperCut opened a note in its bulletin about post-patch problems with external-database Card/ID number lookup and with SAML. Translated: that last error may show up because you patched, not because you were attacked. If you use card lookup against an external database — the vendor says it is a rarely used feature — you need to add security.card-number-lookup.enabled=Y to server/security.properties and restart the Application Server; without that key, PaperCut silently ignores external lookup calls even though the admin interface still shows the feature as configured.
• Does your EDR see that server? A signature-based antivirus will not flag charmap.exe: it is a legitimate Windows binary. What gives the intrusion away is the relationship — an odd child process hanging off the print service — and that is visible to a tool that watches behaviour and process lineage. And do not take it for granted: the agent is not always where you think, as we described when somebody switched off an EDR with a reboot into safe mode.
• Who owns it? Write a name next to that server. Not a department: a name. It is the only one of the six things on this list that still works three years from now, when the next advisory lands.

When this does not apply to you

If you do not use PaperCut, this particular story does not concern you and we are not going to pretend otherwise to stretch the post. And if you do use it, and you are on a patched branch, and its management interface has never seen the internet, you have a short piece of work and little else: apply the second round, check the indicators and get on with your day. Nor are we going to tell you to rush out and buy something: in this incident the control that mattered most — restricting access to the console — costs no money, it costs half an hour of somebody with firewall permissions.

And there is one thing we cannot promise you, and nor can anyone else: that you would have patched in time. Exploitation was seen on the 26th; the advisory came out on the 27th; the good patch on the 28th. No patching process beats that window. What does decide the outcome is everything else: whether the console was on the internet, whether the service ran as SYSTEM, whether anybody looks at that server's logs, and whether there is a tool that would have noticed a strange child process at three in the morning. And if the answer to all of that is bad, the way out the vendor itself recommends is unpleasant but honest: secure your current backups, completely wipe and rebuild the Application Server and restore a clean backup taken before any suspicious behaviour. Look at what sits underneath that sentence: you need to have backups, to know what day each one is from, and to be able to say from when they stopped being trustworthy.

The service door is a door too

In our day-to-day work, the difference between the places where this is settled in an afternoon and the places where it turns into a bad week is not the budget or the firewall vendor. It is whether an inventory exists in which that server has a row, a written version number and a name beside it. That, without decoration, is what we do in IT maintenance: not "patching", but sustaining the state of an entire estate, including the servers we did not install and the ones nobody would classify as critical.

The other half is accepting that some days the patch arrives late, because in this case it arrived late for everybody. At that point the question is no longer "was it patched?", but "how long was somebody inside before we noticed?". That one is answered by monitoring that watches behaviour and process lineage: managed EDR and MDR. And the whole picture — what we expose, with what privileges, and who is watching — is what we mean when we talk about cybersecurity: a pile of small decisions taken before they are needed.

Three years from now there will be another urgent advisory, and it will not be PaperCut. It will be some other unremarkable box that has been running quietly for years, installed by somebody who no longer works here, running with more privilege than it needs. The only thing that works against that future is boring and nobody sells it: that the box has a row on a list, with a version beside it and a name behind it.

Sources (verified one by one, consulted on 29 August 2026): the exploit chain step by step, the activity observed on 26 and 27 August, the whoami & ver and whoami & ver & tasklist commands, the .class files, the proof of concept in which charmap.exe runs as SYSTEM under pc-app.exe (that is their lab, not an observed intrusion: we flag it because several write-ups blur the two), the indicator list, the 25.0.12.76497 (NG) and 25.0.12.76496 (MF) builds — which belong to the first patch —, the figure that 47% of the approximately 2,500 PaperCut installations Huntress tracks are running v23 or older, the incident lasting under two minutes in total and the VPN recommendation — Huntress, "PaperCut Actively Exploited: A Pre-Auth RCE Chain". The Immediate action required section and its "take this action now, even if you have not observed suspicious activity", the full timeline with AEST timestamps, Emergency Patch Release 2 and the installer SHA256 checksums, the FAQ on v23 and earlier, the security.card-number-lookup.enabled=Y key, the 29 August note on post-patch Card/ID and SAML failures, the scope covering Site Servers and secondary servers, Mobility Print being unaffected, the advice to rebuild the server and restore a clean backup on suspected compromise, and the fact that the information came from a university customer's security and DFIR teams — PaperCut security bulletin. The CVE-2026-81578 (CVSS 8.8) and CVE-2026-82078 (CVSS 9.4) identifiers and the quote about restricting web access to trusted addresses — Rapid7, zero-day analysis. The bypasses of the original patches found by watchTowr and Huntress and the additional authentication bypass flaw — BleepingComputer, 28 August 2026. The 2023 precedent, exploitation from mid-April, the Bl00dy Ransomware Gang against the Education Facilities Subsector and the internet-exposed servers — joint CISA/FBI advisory AA23-131A, 11 May 2023. These are ours, and we flag them as judgement rather than published fact: reading the 47% as a server-ownership problem rather than negligence, the idea that a patch is a state and not an event, and the six checks on the list. The "close the access before you patch" ordering is not ours: it is PaperCut's, who put it first in their bulletin.