TL;DR - PaperCut released a second emergency patch for NG and MF on 28 August 2026 because researchers bypassed the first patch from 22 August inside a week. The chain is unauthenticated remote code execution, with active exploitation observed from 27 August. If you run PaperCut NG or MF on a print server that is internet-reachable, behind a customer firewall with port-forwarded web admin, or in a school or library kiosk, you have until Monday morning to confirm you are on the 25.x or 26.x branch. What you need to do: check the version, patch to v25.0.6+ or v26.0.1+ on NG, or the equivalent MF build, hunt
/appand/apiaccess logs for the last 14 days, and assume unauthenticated RCE until you have evidence otherwise.
Two emergency patches in forty-eight hours is not a maintenance release. It is a fire.
On the morning of 28 August I had a half-finished coffee and three PaperCut-related tabs open when BleepingComputer and The Hacker News both filed the second writeup. Researchers had found a bypass to the 22 August patch that PaperCut shipped for an unauthenticated remote code execution chain in PaperCut NG and PaperCut MF. The first patch was supposed to close it. The bypass meant it did not. PaperCut responded with another emergency release the same day. If you are an MSP, a school IT lead, a library systems admin, or an ANZ SMB sysadmin who runs PaperCut on a print server behind a customer network, this is the moment you check the version, not next week.
The original disclosure landed on 22 August via PaperCut's own security advisory. Within five days, exploitation attempts were landing on internet-reachable PaperCut instances. By 27 August, BleepingComputer was reporting active zero-day attacks. By 28 August, the bypass was public and the second patch was out. Three calendar days between first patch and second patch is the cadence you get when defenders and attackers are running neck and neck on the same primitive.
The reason this matters more than a typical vendor advisory is the deployment shape. PaperCut NG and MF are not exotic software. They are the print management layer underneath a large fraction of ANZ schools, TAFEs, libraries, accounting firms, legal practices, and the print rooms of any MSP that runs print-as-a-service for customers. The default install puts a web admin interface on the print server, and in many customer networks that interface is either port-forwarded or behind a permissive firewall rule. Where the admin interface is exposed, the unauthenticated RCE chain is in scope. Where it is internal-only, the chain still matters the moment a phish, a contractor laptop, or a student account gives an attacker a foothold.
By The Numbers
| Metric | Detail |
|---|---|
| Vulnerability class | Unauthenticated Remote Code Execution (chain) |
| Affected products | PaperCut NG, PaperCut MF |
| First emergency patch | 22 August 2026 |
| Active exploitation first observed | 27 August 2026 |
| Second emergency patch | 28 August 2026 (bypass of first patch) |
| Patched branches (NG) | 25.0.6+, 26.0.1+ (per PaperCut advisory) |
| Likely exploitation vector | Unauthenticated HTTP/S requests against /app and /api paths on the admin interface |
| KEV status | Not yet listed on CISA KEV as of 29 August 2026 - add to your internal watch list |
| Customer profile most at risk | ANZ schools, libraries, MSP print rooms, accounting firms running print-as-a-service |
Why PaperCut is the print server that gets hit
Print management is one of those categories where the software sits quietly in the background for years. You install it, you forget about it, and it does its job until the day someone notices an unpatched CVE and the room gets quiet.
PaperCut NG and MF are everywhere because they solve a real problem. They give organisations print quotas, secure print release, account tracking, and a web admin interface that is genuinely useful. The web admin interface is also the surface area. It runs on the print server, it talks to a database, it accepts connections from anyone who can reach it on port 9191 or 9192 (the default) or whatever custom port you chose at install time.
The deployment pattern in ANZ is roughly three shapes. The school or TAFE: PaperCut on a Windows server in the staff server room, web admin exposed on the staff VLAN, student kiosks running the user client. The library: similar shape, often with PaperCut on a Linux VM, web admin reachable from the public desktop VLAN. The MSP print room: PaperCut on a hardened server in the MSP's data centre, web admin exposed to the customer network through a firewall or VPN, often with port forwarding for the print release interface so students and remote staff can pull jobs. Every one of those shapes has a network path from outside the server itself to the admin interface, and that path is the chain.
When an unauthenticated RCE lands on the admin interface, the attacker has the print server. From there they have whatever the print server can reach. In the school shape that is the staff file share, the student management system, and usually Active Directory. In the MSP shape that is every customer network the print server talks to, plus whatever credentials are stored in the PaperCut config. In the library shape it is the catalogue, the patron database, and the management workstations. The unauthenticated RCE does not have to be flashy. It has to be reachable.
The bypass that triggered the second patch
The 22 August patch was meant to close the chain. Researchers spent the next five days reverse-engineering it and found a path around it. The details, per the public reporting, involve a combination of crafted HTTP requests against /app and /api endpoints that the first patch did not fully cover. The full technical walk-through is in the BleepingComputer and The Hacker News writeups linked below. The practical meaning is simpler: if you patched on 22 or 23 August and stopped, you have an incomplete fix.
The second patch on 28 August is the one that closes both paths. If you patched on 22 August and stopped, you are behind again. If you have not patched at all, you are exposed to both the original chain and the bypass.
The reason this matters operationally is that ANZ print rooms are not usually on a tight patch cadence. They are stable, they work, and the people who own them are often one of the IT-pros in a small team who has eleven other things on the list this week. The print server is exactly the kind of asset that gets pushed to the bottom of the queue, and exactly the kind of asset an active zero-day campaign will land on.
The one-hour print server checklist
This is the job for today and tomorrow. It does not require a vendor call, a new tool, or a change advisory board. It requires a quiet hour and the admin interface for each PaperCut instance you can think of.
Step 1 - Find every PaperCut instance (15 minutes)
Query your RMM tool, your cloud accounts, and your documentation for anything running PaperCut NG or MF. The default ports are 9191 (NG/MF admin) and 9192 (NG/MF user). Any open port on those numbers is a candidate. Also check for PaperCut MF running on IIS (common in schools and TAFEs) versus running on a Linux box behind Apache (common in libraries and MSPs). The install shape changes the patch path.
If you are an MSP, check your customer documentation for every customer that has a print-as-a-service contract. The PaperCut instance may be in your infrastructure or it may be on a customer server you only manage remotely. Either way, it is in scope.
If you do not have a documentation system that lists this, the absence is itself a finding. Write it down.
Step 2 - Confirm the version and the branch (10 minutes)
Log into each PaperCut admin interface and check the version. The version is on the About page or in the footer of the admin dashboard. You are looking for either a 25.x build at 25.0.6 or higher, or a 26.x build at 26.0.1 or higher. Anything below those on the 25 or 26 branches is missing the second patch. Anything on a 24.x or older branch is missing both patches.
PaperCut MF uses a parallel numbering scheme but the same rule applies - the second patch is the one that closes the bypass, and you want to be on the build that has it. The PaperCut advisory linked below lists the exact build numbers for each branch.
Step 3 - Check internet and admin reachability (10 minutes)
For each instance, ask three questions. Is the admin interface (port 9191 or 9192) directly reachable from the public internet? Is it reachable from the staff VLAN only? Or is it reachable from inside the customer network but behind a firewall with rules that allow external print release?
If the answer to any of those is "yes, it is reachable from somewhere it should not be", the instance is in scope for the active campaign. Move to Step 4 immediately for that instance.
Step 4 - Patch to the second-patch build (15 minutes)
For NG on the 25 branch, upgrade to 25.0.6 or higher. For NG on the 26 branch, upgrade to 26.0.1 or higher. For MF, use the equivalent MF build from the advisory. The patch is a normal PaperCut upgrade - download the installer, run it, accept the defaults, let the database upgrade. In most deployments this takes less than ten minutes per instance.
If you cannot patch right now - say the instance is on a custom configuration that has not been documented - block the /app and /api paths at the firewall as a temporary measure. This stops the exploitation vector without requiring a full upgrade. It is a temporary measure only.
Step 5 - Hunt the last 14 days for exploitation attempts (15 minutes)
Pull the PaperCut access logs and the web server access logs for the last 14 days. You are looking for a small set of indicators. POST requests against /app or /api paths that returned HTTP 200 or HTTP 500 from anonymous sources. Any request against paths that do not appear in normal PaperCut admin usage. Any request from a source IP that is not in your expected admin or print release range. Any request that contains encoded payloads or unusual query strings against the /app or /api paths.
If you find hits, you have attempted exploitation, not necessarily successful exploitation. Move to Step 6.
Step 6 - If exploitation is confirmed, treat it as a full incident (timing varies)
If your logs show successful exploitation - HTTP 200 responses against the /app or /api paths from anonymous sources followed by other suspicious activity - treat the print server as compromised. Rotate every credential stored on or reachable from that server. Review Active Directory for any account that authenticated to the print server in the last 14 days. Pull the PaperCut database and look for new admin accounts you did not create. Check the print server's outbound connections for the last 14 days - PaperCut should be talking to your database and your licensing server, nothing else.
This is the part where you wish you had been patching the print server every month. The post-incident cleanup is much more expensive than the patch.
What "internet-reachable" actually means in 2026
I want to be specific about this because the most common reaction I see from MSPs is "it is not internet-reachable, it is behind the firewall." That is good. It is also not the whole story.
The chain is unauthenticated. The attacker does not need credentials. They need a network path to the admin interface. The path can be direct (port 9191 forwarded from the firewall to the public IP), indirect (a staff VPN endpoint that hands out access to the staff VLAN, which then reaches the admin interface), or accidental (a student kiosk with a browser that can hit the admin interface on the local network because the firewall rules were written for the user client, not the admin).
In a school, the student kiosk pattern is the riskiest. Students can browse to the admin interface from a kiosk because the kiosk is on the staff VLAN by accident, or because the firewall allows outbound to local subnets without restriction. In an MSP, the print release port forwarding is the riskiest. In a library, the patron desktop VLAN is the riskiest.
The fix in each case is the same: check whether the admin interface is reachable from a network path that is reachable from a network path that is reachable from a non-trusted source. If yes, patch today.
The KEV question
CISA's Known Exploited Vulnerabilities catalog had not added the PaperCut chain as of the morning of 29 August. That does not mean the chain is not being exploited - BleepingComputer and The Hacker News both reported active exploitation on 27 and 28 August. It means the federal due-date clock has not started yet.
For ANZ operators, the KEV status is informative rather than determinative. The Security of Critical Infrastructure (SOCI) Act in Australia and the equivalent obligations in New Zealand reference CISA KEV as a useful input but do not make it a hard deadline. Your cyber insurance underwriter will care. Your enterprise customers will care if they have a third-party risk management program that tracks CISA feeds. Treat the PaperCut chain as a KEV-equivalent priority and patch this week.
Frequently Asked Questions
Q: We run PaperCut MF on Windows Server 2019 in the staff server room. Are we exposed?
A: Possibly. If the admin interface on port 9191 or 9192 is reachable from anywhere outside the server itself - student VLAN, staff VLAN with permissive rules, port-forwarded from the firewall, or reachable through a VPN endpoint - you are in scope. Check the version (Step 2) and the reachability (Step 3) above.
Q: We patched on 23 August. Are we safe?
A: No. The 23 August patch is the first emergency patch. The 28 August patch is the one that closes the bypass. If you stopped at the first patch, you are missing the second one. Upgrade again.
Q: Our PaperCut is behind a firewall with no port forwarding. Do we need to patch?
A: Yes. The chain is unauthenticated, which means any internal foothold - phish, contractor laptop, student account, vendor remote support session - gives an attacker a path to the admin interface. Patch this week even if you are not internet-reachable.
Q: We use PaperCut Cloud. Is this our problem?
A: No. PaperCut Cloud is the hosted version and the vendor applied both emergency patches on their side. The problem is for self-hosted NG and MF only. Confirm with your PaperCut account rep if you are not sure whether you are on Cloud or MF.
Q: How do I know if we were exploited before we patched?
A: Check the PaperCut access logs for POST requests against /app or /api paths from anonymous sources in the last 14 days. If you see HTTP 200 responses followed by unusual database queries or new admin accounts, treat the server as compromised.
Further Reading
- PaperCut second emergency patch - BleepingComputer, 28 August 2026 - the cleanest writeup of the bypass and the second patch
- PaperCut NG/MF zero-day first reported - BleepingComputer, 27 August 2026 - the original active exploitation reporting
- Attackers chain two PaperCut flaws for unauthenticated RCE - The Hacker News, 28 August 2026 - the chain breakdown
- PaperCut zero-day exploited in attacks - The Hacker News, 28 August 2026 - the active exploitation summary
- PaperCut release notes and patch downloads - the vendor's blog surface where the v25 / v26 release notes are posted (the vendor's own security-advisories URL went 404 the week of the second patch; the blog stays current)
- August Patch Tuesday: ANZ SMB priorities - how PaperCut fits into the broader August patch cadence
- Metabase zero-day week two: SMBs got hit first - a parallel IT-pro self-hosted incident playbook
- CISA Known Exploited Vulnerabilities catalog - the federal tracking feed to add to your internal watch
If you run print-as-a-service for customers, or you own the print room at a school, TAFE, library, or accounting firm, the version check takes ten minutes. The patch takes another ten. The hunt takes fifteen. Total cost of the job: under an hour per instance, and the alternative is a print server incident that costs you a week. Forward this to the person who owns the print servers at your customers, before the students go back on Monday.
Mathew Clark Founder, SecureInSeconds Currently: going through my own list of PaperCut instances and wondering which one I have not touched in eighteen months.
