Every advisory about a PaperCut NG vulnerability finishes with the same instruction: patch to the fixed release. Correct advice, and close to useless on its own, because the organisations that get hurt are rarely the ones that refused to patch. They are the ones that patched the print server they knew about and missed the two nobody had logged.
Print management is an operations tool. It gets installed by IT operations, by facilities, or by the copier supplier during an equipment refresh, and it very often never reaches the asset register the security team scans. In external discovery work, PaperCut instances turn up on branch office IP ranges that were never flagged as in scope. That is the actual risk, and it is a discovery problem before it is a patching problem.
This piece walks through what the recurring PaperCut flaws let an attacker do, how to fingerprint every install you own from the outside, a 72 hour containment and remediation sequence, and how to prove to a board that exposure is closed rather than assumed.
PaperCut NG and PaperCut MF share the same application server codebase, so security issues almost always affect both. The flaw classes repeat, and understanding the pattern matters more than memorising CVE numbers.
Authentication bypass to the admin interface. Certain request paths have historically been treated as pre-authentication setup or session endpoints, letting an unauthenticated request land inside an administrative session. Once an attacker holds the admin console, they do not need a memory corruption exploit. The product legitimately supports print scripting and external program execution for user and group synchronisation, so administrative access converts to code execution on the host through documented features.
Unsafe deserialisation and dynamic class loading. Database connection and configuration utilities inside the application server have been found handling attacker-influenced input in ways that allow classes to be loaded or objects deserialised without adequate validation. Different mechanism, same outcome.
Privilege escalation on the host. Service accounts, file permissions and installer paths on Windows print servers give a local foothold a route to SYSTEM.
Why does this server class keep getting targeted? Because a print server is a genuinely attractive position. It runs with high local privilege, it is domain joined, it holds credentials for the database and for directory synchronisation, and every endpoint in the estate trusts it enough to pull drivers and print configuration from it. Attackers get privilege, credentials and reach from one box.
The reference case remains April 2023. CVE-2023-27350, an improper access control issue allowing unauthenticated remote code execution, and CVE-2023-27351, an authentication weakness exposing user information including hashed credentials, were exploited at scale against unpatched servers. Microsoft attributed early activity to an actor linked to Cl0p ransomware operations, and LockBit-linked intrusions followed. CVE-2023-27350 sits in CISA's Known Exploited Vulnerabilities catalog, which is the single fastest sanity check on whether a print management CVE is theoretical.
UK public sector estates have had their own prompts. CVE-2024-1222, rated 8.6 under CVSS v3.1, featured in an NHS Digital advisory covering multiple vulnerabilities in PaperCut MF and NG servers. For authoritative version-by-version detail, PaperCut publishes its own security bulletin and vulnerability log on papercut.com, and NCSC advisories carry the UK context. Use those two sources, not a vendor blog summary, when you set your remediation window.
Do not trust the installer folder name, and do not trust the CMDB entry someone wrote during the original print project. Open the admin console, go to the About area, and read the version and build number the running application server reports. That is the only number worth putting in a change ticket.
Then map the architecture properly, because PaperCut is not one server:
Here is the pattern that catches multi-site organisations. A college runs one Application Server at the main campus plus three Site Servers at satellite campuses. The change ticket names "the PaperCut server", the main campus install is patched, the ticket closes, and two satellite installs stay reachable on 9192 for weeks. Nothing was done wrong procedurally. The scope was simply wrong.
Deployment ownership complicates it further. Cloud-hosted instances, MSP-managed application servers, and OEM-bundled PaperCut MF supplied by copier vendors all sit on someone else's patch schedule. You still carry the exposure.
And treat "we are behind a firewall"as a hypothesis, not a fact. Web Print, Mobility Print, remote site connectivity and print-from-home features all exist precisely to accept traffic from outside the core network, and each one has been the reason a NAT rule or a load balancer listener was created years ago and forgotten. Mobility Print in particular runs its own service with its own listening ports, so check current PaperCut documentation for the ports your version uses rather than assuming 9191 and 9192 cover everything.
PaperCut has an unusually clean external fingerprint, which is good news for defenders willing to look for it.
Default ports are 9191 for HTTP and 9192 for HTTPS, with the admin console at /admin. The login page is distinctive, the setup and page service paths in the application URL structure are recognisable, and TLS certificate subject and SAN fields frequently carry the internal hostname of the print server, which hands you the naming convention for the rest of the estate.
Now the point most organisations miss. Ports 9191 and 9192 are non-standard high ports. An external sweep configured against the common port set returns a clean bill of health while the PaperCut admin console answers happily on 9192. That single scanning gap is the most frequent reason a security team believes it is unaffected when it is not. If your external scanning profile cannot show you 9191 and 9192 results for every range you own, your evidence of non-exposure is not evidence.
Where forgotten instances actually live:
Enumerate before you scan. Pull DNS records and historical subdomain data for print, papercut, mfp, copier and site-code naming patterns, reconcile registered IP ranges and cloud allocations against what the network team believes it owns, and only then sweep. Skipping enumeration is how the sweep comes back clean and the shadow instance survives. Continuous external asset discovery and mapping exists for this reason: an internet-facing asset inventory refreshed once a year describes an estate that no longer exists, and NIST-style inventory expectations assume currency, not an annual snapshot.
Containment first, patching second. Block 9191 and 9192 inbound at the perimeter for every range, not just the one you think hosts PaperCut. Remove NAT rules and load balancer listeners rather than relying on an upstream ACL nobody owns. Inside the console, apply IP allow-listing to the admin interface (in current versions this sits under Options then Advanced, in the security settings, though the exact route moves between releases). Where a business function genuinely needs external print submission, put it behind the VPN or a reverse proxy with authentication in front of it.
Apply the fixed release named in PaperCut's bulletin for your major version, restart the application server and site server services, and confirm the build number in the About page afterwards. Then verify from outside your network. A closed change ticket is a claim. A scan result from an external vantage point is proof.
If the host was reachable, assume interaction until you can show otherwise. Check for admin accounts you did not create, review the audit log for configuration changes around the exposure window, and inspect print scripts and user or group synchronisation program paths for edits, since those are the legitimate features used to execute code. On the host, look for child processes spawned by the PaperCut service, particularly command shells and scripting engines, and review outbound connections from the print server. A print server initiating traffic to an unfamiliar external host deserves immediate attention.
Patching without credential rotation leaves the door open. Rotate the internal PaperCut admin password, the service accounts the application runs under, and any database credentials stored in server.properties. Those credentials are reused elsewhere more often than anyone admits, and CVE-2023-27351 demonstrated that user data including hashed passwords can leave the box without authentication. Once such credentials surface in stealer logs or combolists, the attacker no longer needs the CVE at all. Checking your domains and admin accounts against leaked credential and dark web monitoring sources belongs inside this incident, not in a review three months later.
Re-scan from outside, from more than one vantage point. Mobile networks and a secondary ISP link frequently reveal a path that your primary egress does not, because split perimeter rules and legacy failover circuits rarely receive the same firewall changes. Confirm that 9191 and 9192 refuse connections and that /admin is unreachable, per host, not per site.
Then deal with the noise. One PaperCut host will happily generate findings from infrastructure scanning and web application scanning at once, plus separate entries for HTTP and HTTPS, plus a certificate finding. Twelve tickets, one server. That is how a genuine critical gets buried while a live exploit is circulating and the queue is already full. Deduplication and auto-resolution matter more than raw scanner coverage during a zero-day, and continuous asset monitoring with change tracking gives you the week-on-week delta that makes the report writable.
The management report should be short and factual: PaperCut instances found, instances patched, instances retired, instances still exposed with an owner and a date, and what changed since last week. Push the remediation items into Jira, Slack or Teams so the owner, the action and the verification evidence sit in one trail an auditor can follow without you rebuilding the story from memory.
Write the rule once and stop re-learning it: any administrative console answering on a non-standard high port from an external IP is an exposure finding, regardless of patch level. That rule covers PaperCut, and it covers the next print, backup, monitoring or MFT product to have a bad quarter.
Push it into supplier management too. Copier and managed print providers routinely install and own PaperCut MF as part of an equipment contract, which means you inherit their patch timeline whether you agreed to it or not. Ask for a named patch SLA for critical CVEs, version reporting per site, and current ISO 27001 certification evidence with scope, then monitor the supplier's own external exposure rather than filing the certificate and moving on.
Exploit chatter is the other half. Proof of concept code and target lists for print management software tend to circulate on hacker forums and Telegram channels before mainstream reporting catches up, and knowing a working exploit is in circulation moves the remediation window from next patch cycle to tonight. That distinction is worth more than any severity score.
Finally, set an alert for any new host answering on 9191 or 9192 anywhere in your ranges. Shadow IT installs then surface within days instead of at the next incident. Handled this way, the next PaperCut NG vulnerability becomes a scoped, evidenced piece of work rather than a scramble to establish what you own. If you want a view of your external attack surface built from the attacker's perspective, DarkInvader's free account is a reasonable place to start, and the team can walk through a scoped review of your internet-facing estate.
CVE-2023-27350 was exploited at scale in April 2023 and appears in CISA's Known Exploited Vulnerabilities catalog, with reported activity linked to Cl0p and LockBit ransomware operations. Later issues have varied in whether public exploitation was observed. Check the CISA KEV catalog and PaperCut's own security bulletin for the specific CVE you are assessing rather than assuming either way.
Log in to the admin console and read the version and build number from the About area. The running application reports what is actually installed, whereas installer folders, MSI records and CMDB entries frequently reflect a version that was replaced or upgraded in place. Repeat the check on every Site Server and secondary print server separately.
The admin console should not be. If external print submission is genuinely required, put it behind a VPN or an authenticated reverse proxy and apply IP allow-listing to administrative access. Ports 9191 or 9192 answering from an external IP is a finding worth raising immediately, whatever patch level the server is on.
Look for admin accounts nobody created, unexplained entries in the audit log around the exposure window, edits to print scripts or to user and group synchronisation program paths, command shells or scripting engines spawned as child processes of the PaperCut service, and outbound connections from the print server to unfamiliar hosts. Credential theft is a common follow-on, so treat admin and database credentials as exposed until proven otherwise.
No. Where a copier or managed print supplier installed and administers PaperCut MF as part of an equipment contract, they control the patch schedule and often the host. Request written confirmation of the patched version per site, hold them to a defined SLA for critical vulnerabilities, and verify externally that their ports are not reachable from your ranges.
Unlock full visibility of your external attack surface with DarkInvader’s continuous, real-time monitoring. Create your free account to discover unknown assets, detect emerging risks and stay ahead of potential threats before attackers can exploit them.
Create My Free Account
Platform 7D, New Station Street, Leeds,
LS1 4BT, United Kingdom
Mon-Fri, 9:00-17:00
Contact:
sales@darkinvader.io
+44 (0)1138805336
Last updated: 14 August 2026
©2026 DarkInvader, All Rights Reserved
