The Second PaperCut Patch Still Needs Proof

A university finds suspicious activity on its print-management server. PaperCut reproduces the problem, publishes an emergency patch, then returns hours later with a second patch because outside researchers found more ways around the first response. By the next day, administrators are also reporting that two legitimate features may not work as expected after the update.

That is the uncomfortable shape of the PaperCut NG and PaperCut MF incident as of 29 August 2026. The company says attackers are actively exploiting the products, it knows of confirmed customer incidents, and every version is potentially affected. Its current instruction is to install Emergency Patch Release 2 on supported version lines 24, 25, and 26, while keeping public web access restricted to trusted addresses (PaperCut’s live security bulletin).

The first job is urgent: remove the server’s web interface from the open internet and apply the current patch. The second job is quieter and just as important. Prove that every PaperCut server received the right update, prove that the controls still work after it, and investigate what happened before the fix. A downloaded installer cannot establish that the vulnerable path is gone.

This is a patch story, but it is also a lesson in operating during incomplete information. Emergency fixes arrive before the normal release process has finished. Researchers keep testing. Business features can break. Attackers may have acted while the team was still reading the advisory. The correct response is neither blind confidence nor paralysis. It is a controlled sequence with records at each boundary.

What changed between 27 and 29 August

PaperCut published its initial bulletin on 27 August 2026 after a university customer’s security and incident-response teams supplied information that helped the vendor reproduce the flaw. The company said its own response team was investigating active exploitation and knew of confirmed customer incidents. It did not claim that every exposed installation had been compromised, and it had not publicly attributed the activity to a named group (PaperCut’s bulletin and update log).

An initial emergency patch for PaperCut NG and MF versions 25 and 26 followed at 02:10 Australian Eastern Standard Time on 28 August. Later that day, after work with Huntress and watchTowr, PaperCut published Emergency Patch Release 2 with “additional hardening beyond the original emergency patch.” Version 24 builds followed at 22:08 AEST. The company now recommends Release 2 even for customers who already installed the first emergency patch (PaperCut’s release timeline).

That sequence matters. Someone who patched early on Friday may still be behind the vendor’s current guidance. A change ticket that says “PaperCut emergency patch applied” is too vague to settle the question. The record needs the product, major version, operating system, package checksum, installation time, and confirmation that the running service contains Release 2.

Independent reporting supports the core account. Huntress told The Hacker News that it saw limited exploitation in two customer environments, including commands used to identify the account and operating system. watchTowr said attackers could combine an authentication bypass with unsafe class loading to reach code execution, and both firms continued testing the fixes (The Hacker News report, 28 August 2026). SC Media independently reported that both assigned vulnerabilities affect builds released before 27 August and that emergency packages were available for major versions 24, 25, and 26 across Windows, Linux, and macOS (SC Media’s report, 28 August 2026).

The public details are still moving. The Hacker News reported that watchTowr had identified further bypass paths while testing the latest code. PaperCut’s live bulletin, last updated on 29 August when this article was written, continued to name Release 2 as the current mitigation and said its security team was working through the weekend. That is a reason to monitor the primary bulletin and restrict access, not a reason to abandon the current fix while waiting for perfect certainty.

PaperCut also added an operational warning at 16:35 AEST on 29 August. It had received reports that Security Assertion Markup Language (SAML) sign-in and external database Card/ID lookups were not working as expected after the patch. The company was investigating. This creates a real change-management problem: a security update may interrupt authentication or a specialised lookup feature, but restoring the vulnerable build would reopen a path already used in attacks (PaperCut’s current-status section).

The sensible position is firm. Keep the server out of public reach, use Release 2, test the affected functions, and escalate failures through the vendor. Do not silently roll back because a login flow broke. A rollback is a security decision, not merely a service-restoration shortcut.

How two weaknesses become one route to the server

The two published vulnerabilities do different jobs. CVE-2026-81578 is an access-control failure in the web management interface. Under specific conditions, a request from somebody who has not signed in can trigger administrative backend actions before the application completes its permission check. PaperCut rates it 8.8 under CVSS 4.0 and says it can let an unauthenticated remote caller change certain system configuration (PaperCut’s vulnerability description).

In plain English, the front desk checks the wrong part of the request. The page shown to the caller can appear harmless while a component behind that page performs a privileged action. Huntress described this as a mismatch between the page rendered for the response and the page that owns the action being executed. The authorisation decision can therefore approve the wrapper while missing the authority required by the action inside it (The Hacker News account of Huntress’s analysis).

CVE-2026-82078 sits behind that first weakness. PaperCut’s database connection utilities can instantiate driver classes based on configurable names without limiting those names to an approved set. If somebody can manipulate the relevant configuration, the application may load Java bytecode already present on its classpath and execute it as the PaperCut server process. The vendor rates this issue 9.4, and Rapid7’s vulnerability record carries the same mechanism and score (Rapid7’s CVE-2026-82078 record).

On its own, the second issue requires high privileges according to PaperCut’s score. The chain changes the condition. The first flaw can supply unauthenticated configuration changes; the second can turn a configuration value into code running under the application identity. One weak boundary lends authority to the next.

This is why a severity score on either row cannot describe the whole incident. A team might look at the 8.8 authentication flaw and schedule it behind several 9.8 issues. Another might look at the high-privilege requirement on the 9.4 class-loading flaw and decide that only administrators can reach it. The chain removes that comfort. Attackers care about paths, not spreadsheet rows.

The application identity also matters. Code execution does not automatically mean control of every machine in an organisation, and public reporting does not support that claim. The code runs with whatever files, credentials, network access, and operating-system permissions the PaperCut process has. A dedicated account on an isolated server has a smaller reach than a broadly privileged service on a shared Windows host.

Print management is easy to dismiss as office plumbing. In practice, the application can touch identity directories, card systems, email, databases, printers, archival features, and administrative workflows. Some deployments may retain print-related data. Others may not. The investigation should use the installation’s actual configuration rather than a generic list of everything the product can do.

A useful mental model is a relay. The public web interface passes a request to the management layer. The management layer changes trusted configuration. The database utility interprets that configuration as a class name. The Java runtime executes code under the server’s identity. Each handoff converts data into more authority. The patch has to break the route, while the response team has to ask how far the final identity could travel.

Why public exposure changes the first move

PaperCut’s strongest immediate instruction is about reachability: if the Application Server is accessible from the public internet, restrict its web interfaces to trusted IP addresses now. The company recommends firewall rules, network controls, or an equivalent measure, even when no suspicious activity has been seen (PaperCut’s immediate-action guidance).

Network restriction buys time for patching and investigation. It can still be incomplete. A forgotten reverse proxy, alternate port, virtual private network path, cloud load balancer, or secondary site can preserve reachability that the main firewall diagram does not show.

Start from outside. Resolve every hostname, inspect public cloud listeners, check internet scan data available to your team, and attempt the web route from an untrusted network under an approved test. Then trace the request inward through proxies and load balancers. A firewall rule on the server means little if a public proxy can still forward traffic to it.

Trusted addresses should also be genuinely narrow. Allowing an entire corporate address range can preserve access from guest wireless networks, contractor devices, or compromised endpoints. An administrative virtual private network with strong authentication is better than a broad office range when the business can support it. The goal is to reduce who can present requests to the PaperCut management interface while the software response is still changing.

The reachability check should produce evidence rather than a reassuring sentence. Record the public names, resolved addresses, listening ports, proxy routes, firewall changes, test source, test time, and result. Keep a screenshot or command output where policy allows. Somebody reviewing the incident later should be able to distinguish “we believe it was private” from “an external test could not reach these interfaces after this control changed.”

Do not let a successful block erase the exposure window. If the interface was publicly reachable until Friday afternoon, restricting it on Friday evening stops new requests but does not answer what happened before then. Preserve the old configuration and the exact time of the change. Those two facts determine which logs and external records belong in the investigation.

Patch every server, then verify the running state

PaperCut’s Release 2 packages cover NG and MF major versions 24, 25, and 26 on Windows, Linux, and macOS. Customers on version 23 or earlier are told to upgrade to the latest version rather than wait for an emergency build. The vendor publishes a separate SHA-256 checksum for each product, version line, and operating system package (PaperCut’s Release 2 download table).

Checksums answer a narrow question: did the downloaded file match the package PaperCut listed? They do not prove the installer ran, the service restarted, or the load balancer stopped sending requests to an old node. Use the checksum before installation, then collect running-state evidence after installation.

Inventory tends to fail at the edges. Teams patch the primary Application Server and miss a Site Server, a secondary print server, a disaster-recovery host, a lab clone, or an old migration system still reachable through an internal route. PaperCut’s FAQ says Site Servers and secondary or print servers should also run a patched version. Print Deploy and Mobility Print are not affected by this specific bulletin (PaperCut’s component FAQ).

That is a product distinction worth preserving. “PaperCut” may refer to several installed components, and indiscriminate changes can create more outage without reducing this risk. Build the inventory by role: NG or MF Application Server, Site Server, secondary server, Print Deploy, Mobility Print, and anything else present. Mark which roles require Release 2 under the bulletin.

A clustered or distributed deployment needs node-level proof. A browser may show a healthy login page served by one updated node while another node behind the same address still runs old code. Query each node directly where possible. Check process start time, installed package version, service binary or archive metadata, and the package record for that host. Then exercise the shared address to confirm traffic is returning only from expected nodes.

The same caution applies to replacement automation. A patched virtual machine can be correct today while its golden image, container layer, configuration-management package, or disaster-recovery template still carries the vulnerable build. The next scaling event or restore can reintroduce it. Update the source used to create servers, not only the servers currently running.

Emergency Patch Release 2 did not complete PaperCut’s usual release process, according to the vendor. That is normal for an emergency response, but it changes the test plan. Confirm the service starts, administrators can sign in, print flows continue, jobs reach expected queues, site servers reconnect, backups complete, and relevant integrations work. Pay special attention to SAML and external database Card/ID lookups because PaperCut was investigating reports about those features on 29 August (PaperCut’s post-patch status note).

The external database lookup feature has an explicit post-install requirement. PaperCut says customers who use it must set security.card-number-lookup.enabled=Y in server/security.properties and restart the Application Server. The default is off, and the administration interface may still appear configured while lookup calls are silently ignored. That is exactly the kind of quiet failure a process check will miss (PaperCut’s external database FAQ).

A good completion record therefore has four layers. The package was obtained from the vendor and matched the published checksum. Every relevant node installed Release 2 and restarted. The running service reports or otherwise demonstrates the expected state. The workflows that matter to users and security controls passed an explicit test.

A clean log is not a clean server

PaperCut has published several possible indicators of compromise. They include security-tool alerts involving the Application Server, suspicious child activity from pc-app.exe, missing or unexpectedly truncated server.log files, and two specific error patterns in that log. The vendor also says the absence of these indicators does not confirm that a system was unaffected (PaperCut’s investigation guidance).

That final sentence should shape the search. An indicator is a lead, not a health certificate. The Hacker News reported that observed code deleted output and log files after gathering basic system information in some incidents. If that account is accurate, missing evidence may itself be part of the activity, while a normal-looking remaining log cannot cover what was removed (The Hacker News incident details).

Begin with preservation. Save application logs, reverse-proxy logs, firewall records, endpoint-security telemetry, process records, authentication events, file metadata, and relevant backups before routine rotation or a rebuild removes them. Record time zones. A PaperCut event stamped in local server time will not line up cleanly with a cloud firewall using UTC unless the investigator knows both clocks.

Search beyond the application. Code running as the PaperCut service can create child processes, read files available to that identity, and make network requests allowed from the host. Endpoint detection may show a short-lived process even when server.log is gone. A proxy may retain the incoming request. A firewall may show a new outbound destination. An identity provider may record a change or unusual sign-in linked to a credential reachable from the server.

Define the window honestly. The public bulletin began on 27 August, but that is not proof that exploitation began that day. Use the earliest suspicious event, the period of public exposure, the known vulnerable deployment date, and the retention available in each data source. If the proxy keeps seven days and the endpoint tool keeps thirty, say which questions each source can answer.

PaperCut recommends that organisations which suspect compromise secure current backups, wipe and rebuild the Application Server, and restore a clean backup from before suspicious behaviour. It also tells customers to activate their normal incident process. The company correctly notes that it cannot assess the full impact inside an individual environment (PaperCut’s compromise FAQ).

A rebuild handles persistence on the server better than installing a patch over a system somebody may already control. It does not revoke a copied password, API key, database credential, or service token. Map what the PaperCut process could read and where it could connect. Rotate reachable identities in an order that does not reconnect a clean server to an account still under doubt.

The investigation should also cover print-related data according to local configuration and policy. Do not assume every job’s document content was stored, and do not assure people that nothing sensitive was available without checking. Identify what the application retained, for how long, under which paths or databases, and whether the service identity could read it.

Confidence comes from independent records. A server-local log controlled by the affected process is useful, but an external endpoint platform, network sensor, identity system, database audit trail, or central log service is harder for the same process to rewrite. Compare them. Gaps deserve a label, not a guess.

Handle patch breakage without reopening the door

Emergency security work often puts two risks in the same room. The old version has a known attack path. The current patch may disrupt a critical workflow. Treating availability as irrelevant will lose the trust of operations teams; treating rollback as harmless can put a vulnerable service back online during active exploitation.

Start by separating reachability from function. If SAML sign-in fails after Release 2, keep the web interface restricted while administrators use an approved recovery route and work with PaperCut support. If external Card/ID lookups fail, verify the required security property and restart before concluding that the patch itself is unusable. Preserve logs from the failure because they can help distinguish an expected default change from a new defect.

Create a rollback gate before anyone feels pressure to use it. The gate should require a named security owner, a documented business impact, the vendor’s latest guidance, confirmation of compensating network controls, and a time-limited plan to return to fixed code. An automatic rollback triggered only by a failed synthetic login is dangerous here. It can faithfully restore a build the vendor has told every customer to replace.

Temporary alternatives should be smaller than the original exposure. A tightly controlled local administrative account for a short period may be safer than reopening the interface to the internet so federated login works. Manual card lookup may be unpleasant but safer than enabling broad database behaviour without understanding the new setting. The exact choice belongs to the organisation, but the direction is clear: restore the minimum function without restoring public attack surface.

Watch the live bulletin after the change. PaperCut said its response team would continue working over the weekend, and the page had already changed several times by 29 August. Assign an owner to check for a new release, revised indicators, support notes, or a change to affected components. “Subscribed to vendor notifications” is useful only when somebody owns the resulting alert.

Testing needs a security half as well as a business half. Confirm untrusted addresses cannot reach the interface. Confirm expected administrators can. Verify the external lookup default matches your intended design. Review service permissions after installation. Check that logging still reaches the external destination and that endpoint monitoring remains attached to the process.

Do not test the vulnerability against production with an exploit copied from public discussion. The vendor’s installation state, network restriction, node inventory, and benign functional checks provide safer evidence while the incident is live. If exploit validation is necessary, use an authorised isolated environment and a qualified security team. Production recovery is not the place for improvised offensive testing.

The patch can reveal weak operational design. If the team cannot tell which package is installed, reach each node directly, test SAML without public exposure, or rotate the service account without a prolonged outage, record those as engineering work. They will matter in the next emergency even when the product name is different.

What to do today

The response works best as one sequence, with containment and evidence collection beginning before the maintenance window. Keep each result. A future reviewer should be able to reconstruct what the team knew and which state it verified.

1. Find every relevant PaperCut component. Inventory NG and MF Application Servers, Site Servers, secondary or print servers, version lines, operating systems, network addresses, and owners. Mark Print Deploy and Mobility Print separately because PaperCut says those components are not affected by this bulletin.

2. Remove public web access. Restrict Application Server interfaces to trusted administrative routes using firewalls, load balancers, proxies, or network controls. Test from an untrusted network and record the result. Keep the restriction after patching while the vendor’s investigation continues.

3. Preserve the exposure facts. Record when each interface was reachable, when restrictions changed, and which vulnerable version was running. Save application, proxy, endpoint, network, identity, and system evidence before logs rotate or hosts are replaced.

4. Obtain Emergency Patch Release 2 from PaperCut. Select the correct NG or MF package for version 24, 25, or 26 and the correct operating system. Compare its SHA-256 value with the vendor’s table. Customers on older version lines should follow PaperCut’s instruction to move to the latest version.

5. Patch every required server role. Update the Application Server, Site Servers, and secondary or print servers identified by the bulletin. Update images and recovery templates that can recreate them. Do not let one healthy node stand in for a distributed deployment.

6. Verify the running state. Confirm each process restarted into Release 2, inspect package or service metadata, query nodes directly, and check that shared traffic reaches only updated nodes. Store the evidence with the change record.

7. Test business and security controls. Exercise sign-in, print flow, site connections, backup, logging, and critical integrations. Test SAML and external database Card/ID lookup deliberately. Apply PaperCut’s documented property for the latter when used, then confirm the lookup really occurs rather than trusting the administration screen.

8. Hunt across independent data sources. Search for PaperCut’s current indicators, missing or shortened logs, unusual child processes, new outbound connections, configuration changes, and identity use during the exposure window. Treat a search with no hits as one piece of evidence, not clearance.

9. Escalate suspected compromise. Isolate affected systems, activate the incident process, preserve backups, and follow PaperCut’s rebuild guidance. Revoke credentials and tokens the service could access, then restore from a point that predates suspicious activity when the evidence supports it.

10. Monitor the vendor bulletin. Give one person responsibility for updates and record each check. Release 2 was current as of this writing on 29 August 2026, but the response had changed repeatedly in less than two days.

A smaller organisation may combine several roles in one person. The sequence still helps. Contain, preserve, patch, verify, test, investigate, and keep watching. Skipping the verification step is how an old node, stale image, broken login, or silent lookup failure survives a green change ticket.

The durable control is installation proof

Teams often measure patching by activity: tickets closed, packages pushed, reboot commands sent. Incidents care about state. Which code is answering requests? Which interfaces can an untrusted person reach? Which nodes missed the deployment? Which business and security controls still work after the change?

PaperCut’s two emergency releases compress that difference into one weekend. An administrator could act quickly, install the first patch, and still need to act again. Another could install Release 2 on the main server while a Site Server remains old. A third could update every binary and miss that SAML no longer works or a specialised database lookup is silently disabled.

Installation proof joins those fragments. It ties the vendor package to its checksum, the package to each node, each node to the running service, and the service to benign functional tests. It also keeps patching separate from incident clearance. Fixed code reduces future risk; external evidence and credential review tell you what may have happened earlier.

That pattern belongs in normal operations, not only emergency weekends. Build node-level version reporting. Keep service inventories current. Test recovery paths before a security release breaks the usual login. Send logs beyond the host that creates them. Give internet-facing administration routes an owner and an expiry date. Make rollback require the same security review as deployment.

The Secure Harness applies this idea to systems that can take consequential actions: trust should cross a boundary only with an inspectable decision and a record. A print server is not a coding agent, but the operating lesson is identical. An action saying “patch installed” needs a harness around it: approved input, bounded target, observable execution, and verified result.

As of 29 August 2026, the public facts support a narrow conclusion. PaperCut says all NG and MF versions are potentially affected, active exploitation has occurred, and Release 2 is its current emergency fix for supported version lines. Researchers have continued finding paths around earlier work, and the vendor is investigating post-patch feature problems. Restrict access, install the current fix, and retain enough evidence to change course if the bulletin changes again.

Speed matters here. Proof keeps speed from turning into theatre. The goal is a server that is unreachable from the wrong place, running the intended code on every node, still performing its legitimate job, and backed by an honest account of the hours before it was fixed.

For one practical email each month on making security work in ordinary systems, join the newsletter on Cyber Security in Plain English.

Sources

• PaperCut: Urgent Security Advisory, PaperCut NG/MF Security Bulletin, 27 August 2026, accessed 2026-08-29.
• The Hacker News: Attackers Chain Two PaperCut Flaws to Execute Code Without Authentication, accessed 2026-08-29.
• SC Media: PaperCut Issues Emergency Patches for Actively Exploited Critical Vulnerability, accessed 2026-08-29.
• Rapid7: CVE-2026-82078, PaperCut MF/NG Unsafe Dynamic Class Loading, accessed 2026-08-29.