PaperCut RCE vulnerability: The Emergency Patch Didn’t Hold Either

By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)

Read this in 30 seconds: PaperCut RCE vulnerability, CVE-2026-81578 (CVSS 8.8, auth bypass) and CVE-2026-82078 (CVSS 9.4, unsafe dynamic class loading) chain together into unauthenticated remote code execution on PaperCut NG and MF, the same print-management software that Cl0p and LockBit affiliates rode into ransomware deployments back in 2023. PaperCut shipped an emergency patch on August 27-28, 2026, and within days watchTowr Labs found multiple ways around it plus a brand-new auth bypass, forcing a second emergency patch (Release 2).

CISA added both CVEs to its Known Exploited Vulnerabilities catalog on August 31. Huntress, tracking roughly 2,500 PaperCut installations, found 47% still running version 23 or older, versions that were never in scope for either patch. If you run PaperCut NG or MF anywhere in your print or document workflow, this is the same failure pattern that fed a ransomware wave three years ago, and the fix this time didn’t work on the first try.

A vendor’s own emergency patch getting bypassed within days isn’t a footnote. It’s the headline.

PaperCut has been down this road before. CVE-2023-27350 became one of the defining ransomware-delivery vulnerabilities of that year, exploited by Lace Tempest to drop Cl0p and by other affiliates to drop LockBit, both riding the same print-server access into full domain compromise. Three years later, a new authentication bypass and a new unsafe-deserialization-adjacent flaw chain into the same outcome, pre-auth RCE on the same product, and this time the first attempt at a fix wasn’t good enough either.

What CVE-2026-81578 and CVE-2026-82078 Actually Do

The chain works in two stages. CVE-2026-81578 is an improper access control flaw in PaperCut’s web management interface, rooted in how the product uses the Apache Tapestry framework. Tapestry’s “complex direct” request format lets a single request name one page to *display* and a different page containing a *component* to actually execute. PaperCut only validates access to the page being displayed, not the component being invoked. By pointing the display target at a public page (the Error or Exception page, which requires no login), an attacker smuggles a request that executes privileged administrative components belonging to ConfigEditor or UserList without ever authenticating.

That gets an attacker unauthenticated access to reconfigure PaperCut’s external database connection settings. CVE-2026-82078 is what turns that access into code execution: PaperCut’s database connection utilities instantiate JDBC driver classes based on a configurable driver name, with no allowlist restricting which classes are actually valid drivers. Point that configuration at a malicious class, and the application loads and executes attacker-controlled Java bytecode inside the Application Server process. Two flaws, one unauthenticated HTTP request each, full RCE.

The Patch That Needed a Second Patch

PaperCut shipped its first emergency patch for the v24, v25, and v26 branches starting August 27-28, 2026, hours after acknowledging active exploitation against customers. That should have been the end of it. It wasn’t. watchTowr Labs reproduced the vulnerabilities, found multiple ways to bypass the initial patch, and identified an additional, previously unknown authentication bypass in the process. PaperCut, working with watchTowr and Huntress, pushed a second emergency patch, Release 2, adding hardening the first patch missed.

That’s the part worth sitting with: this wasn’t a case of a slow vendor ignoring a report. PaperCut patched fast, in under 24 hours of confirming exploitation, and independent researchers still broke it within days. Fast isn’t the same as complete, and for a vulnerability chain this exploitable, the gap between “patched” and “actually fixed” is exactly where attackers who were already inside your network before the first patch get to stay there.

The Indicators Researchers Are Actually Seeing

Huntress’ incident writeup gives specific, checkable indicators rather than vague guidance:

• Base64-encoded reconnaissance commands appearing in server.log, including strings that decode to commands like whoami & ver
• Unexpected .class files dropped under the server/lib directory, with observed filenames like Udydn.class and Moo97.class
• Derby database log entries referencing a memory:pwn connection string, a fairly unsubtle signature if you know to look for it
• Deleted or unexpectedly truncated server.log files, consistent with an attacker covering tracks

Huntress, which tracks roughly 2,500 PaperCut installations across its customer base, confirmed exploitation on two of them directly and found that 47% of the installations it tracks are still running version 23 or older, versions that predate both emergency patches entirely because they were never in scope for either release.

Who’s Exposed

This hits PaperCut NG and MF versions 24, 25, and 26 before the Release 2 patches, and it hits the older, unsupported version 23 and earlier branches permanently, since PaperCut isn’t backporting fixes to end-of-life releases. If your organization runs PaperCut for print management, and a lot of universities, hospitals, and government agencies do, check your version against the advisory now, not on your next patch-cycle date.

What To Do Right Now

1. Confirm you’re on Release 2, not just the original emergency patch. If you patched on August 27-28 and haven’t checked back since, you’re likely still running the version watchTowr broke.
2. If you’re on version 23 or older, you have no patch. Remove the PaperCut Application Server from public internet exposure immediately and restrict access to trusted internal IP ranges while you plan an upgrade.
3. Hunt the specific IOCs above across every PaperCut server log you have, the base64-decoded command strings and the memory:pwn Derby connection string are concrete enough to grep for directly.
4. Assume compromise if you were internet-facing and unpatched between late August and now, and treat a positive IOC match the way you’d treat any confirmed foothold, credential rotation and lateral-movement hunting, not just a patch.

How XHack Treats “The Patch Already Shipped” as Step One, Not the Finish Line

So yeah, brand note: this is the exact scenario a version-check scanner gets wrong twice, once when it says you’re vulnerable before you patch, and once when it says you’re safe right after you patch something that turned out to still be broken.

The XHack AI agent doesn’t stop at confirming a patch installed, it probes whether the underlying behavior the patch was supposed to close actually closed, the same gap watchTowr found by hand. For software that sits this deep in daily operations, print servers touch every department, human-led VAPT catches a patch that didn’t hold before the next researcher’s writeup does it for you. XHack doesn’t store your findings on our servers either, which matters more when the finding is “your emergency patch from three days ago wasn’t actually the fix.”

FAQ: PaperCut RCE Vulnerability Questions Answered

What is the PaperCut RCE vulnerability?

The PaperCut RCE vulnerability is a two-step attack chain combining CVE-2026-81578 (an authentication bypass in the web management interface, CVSS 8.8) with CVE-2026-82078 (unsafe dynamic class loading in database connection utilities, CVSS 9.4). Chained together, an unauthenticated attacker can execute arbitrary Java bytecode on the PaperCut Application Server with a single crafted HTTP request for each stage.

Is my PaperCut installation affected?

If you run PaperCut NG or MF version 24, 25, or 26 on a build before the Release 2 emergency patch (issued after August 28, 2026), you’re affected. If you run version 23 or earlier, no patch exists for your branch, you’re affected permanently until you upgrade to a supported version.

Why did PaperCut need a second emergency patch?

Independent researchers at watchTowr Labs reproduced the original vulnerabilities after PaperCut’s first emergency patch shipped, and found multiple ways to bypass that patch along with an entirely new authentication bypass PaperCut hadn’t addressed. PaperCut worked with watchTowr and Huntress to ship Release 2 with additional hardening within days of the first patch.

How do I know if my PaperCut server has already been compromised?

Check server.log for base64-encoded command strings (decoding to things like whoami & ver), unexpected .class files under the server/lib directory, Derby database log entries referencing a memory:pwn connection string, and any unexpectedly deleted or truncated log files. Any of these warrants full incident response, not just applying the patch.

Is this related to the 2023 PaperCut ransomware attacks?

Not the same vulnerability, but the same product and the same failure pattern. CVE-2023-27350 was exploited by ransomware affiliates linked to Cl0p and LockBit to gain initial access via PaperCut in 2023. This new chain doesn’t share code with that flaw, but it hits the same class of pre-auth RCE on the same widely-deployed print management platform, exactly the kind of access ransomware operators have already shown they know how to monetize.

The Bottom Line

PaperCut’s new RCE chain is a reminder that “the vendor shipped a patch” and “the vulnerability is fixed” aren’t always the same sentence, especially for a vulnerability this exploitable and a vendor working under active-exploitation pressure. If you run PaperCut NG or MF, confirm you’re on Release 2 specifically, not just any patch dated this week, hunt for the IOCs above regardless, and if you’re still on version 23 or older, pull it off the public internet today. A ransomware crew already used this product as a front door once. Don’t find out the hard way whether they’re willing to use it twice.