PaperCut exploitation became a more urgent identity-security problem on September 5, 2026, when The Hacker News reported that attackers were using the active PaperCut NG/MF attack chain to steal credentials from K-12 schools and universities in the United States and Europe. The newly reported activity is not merely opportunistic scanning. Arctic Wolf researchers observed command execution, reconnaissance, privileged-account creation, and collection activity after compromise.
That detail changes how schools should think about a print-management server. It is not background office equipment. It is a high-trust system that can sit near directory services, student and staff identities, print queues, stored documents, and administrative networks. Once an attacker turns it into a credential-collection point, the question is no longer whether printing is disrupted. It is which other systems the stolen identities can reach.
Key Takeaway: Treat a compromised PaperCut server as an identity incident, not a printer outage. Patch it, isolate it, investigate its access to directory services, and rotate exposed credentials from a clean administration path.
Why the new PaperCut reporting matters now
The September 5 report is the freshness hook. The underlying PaperCut flaws were already public, and the vendor issued emergency fixes in late August. The new reporting adds the operational fact defenders need most: attackers have reportedly used the chain against education organizations with credential theft as a post-exploitation objective.
The pair of flaws involves an authentication-bypass path, CVE-2026-81578, and a remote-code-execution path, CVE-2026-82078. That combination can let an attacker move from unauthenticated access to code execution on a vulnerable PaperCut NG or MF server. Earlier reporting described active exploitation and the vendor's emergency response. The September 5 coverage makes the impact more concrete: compromised servers were used to discover systems, create privileged accounts, inspect configuration data, and collect credential material.
This is a dangerous progression for education environments because print infrastructure is often quietly embedded in everything else. A PaperCut server may be integrated with Active Directory or LDAP, receive service-account credentials, connect to file shares, manage mobile-print workflows, or sit on a network with administrative reach. It can be low on the patching priority list while still holding a privileged place in the environment.
PaperCut's own security bulletin says it is investigating active exploitation, recommends immediately restricting public web access to trusted IP addresses, and provides Emergency Patch Release 3. That is a useful baseline. The new reporting adds the reason not to stop at the update: if a server was exposed before remediation, it may already have become a launch point for identity compromise.
How a print server turns into an identity foothold
Print-management software needs to know who people are. That is normal. It uses identity data to assign print quotas, release held documents, apply departmental rules, and let students or staff authenticate to devices. The security problem is that this normal function can make the server a rich target.
An attacker who gains code execution does not need to begin with a dramatic ransomware payload. Quiet discovery can be more valuable. They can identify the account under which the service runs, inspect processes and configuration files, look for directory-service settings, and determine which nearby systems are worth pursuing.
The reported campaign makes that risk tangible. The post-exploitation behavior included host and user discovery, privileged-account creation, Windows registry-hive collection tools, and searches for sensitive configuration values. Those actions are consistent with an attacker trying to convert one exposed application server into reusable identity material.
The practical chain looks like this:
- an exposed, vulnerable PaperCut server provides the initial opportunity
- the authentication bypass and code-execution weaknesses give the attacker a foothold
- the attacker maps the server, its identity context, and connected services
- configuration files, service accounts, or local credentials become collection targets
- stolen credentials can support lateral movement, cloud sign-ins, or later fraud
This is why treating the issue only as a printing problem is a mistake. A print queue might be the visible service, but the high-value asset is the identity and access path behind it.
Common Mistake: Patching the PaperCut application and declaring the incident closed without asking which credentials the server could read, cache, use, or reach while it was vulnerable.
Why schools and universities are exposed differently
Education environments carry a difficult mix of scale, openness, and operational constraints. A university may have tens of thousands of identities, decentralized departmental IT, shared labs, guest networks, research systems, and older servers that cannot be taken down casually. A school district may have limited security staffing while supporting students, teachers, administrators, and many sites.
Print services can fall between those ownership lines. Facilities may see them as devices. IT may see them as an application. Identity teams may not see them at all until something goes wrong.
That ambiguity is attacker-friendly. A compromised print-management server can offer a path into systems that are more valuable than the print service itself:
- directory accounts and service identities
- student, staff, and faculty records
- financial-aid or payment workflows
- research networks and shared storage
- cloud applications protected by reused or synchronized credentials
The danger is also timing. Credential theft often produces less visible disruption than ransomware. A school may not know the server was compromised until an attacker reuses an account elsewhere, sends convincing phishing messages from a trusted mailbox, or reaches a partner environment months later.
The durable lesson is simple: low-profile infrastructure can still be a high-value identity asset. Inventory and patch priority should follow trust and reach, not whether the system is glamorous or user-facing.
What to do in the first 24 hours
If your organization runs PaperCut NG or MF, start by finding every instance. That includes primary production servers, old departmental deployments, test systems, disaster-recovery nodes, and systems managed by third parties. Do not assume that a central IT inventory is complete.
1. Remove unnecessary public exposure
PaperCut advises restricting Application Server web access to trusted IP addresses. Confirm with network evidence, not assumptions, that internet-facing management paths are blocked. A system intended for internal printing should not have a public administrative surface by default.
If remote administration is necessary, place it behind a controlled path such as a VPN or tightly limited access gateway. Limit administrative reachability to known management workstations and networks.
2. Apply the current emergency release
Install the current PaperCut emergency patch and confirm the version on every instance. The vendor says Emergency Patch Release 3 supersedes the earlier emergency releases and adds hardening and mitigation for potential attack chains. Record the completion time, operator, and affected hosts so you can prove that every system was addressed.
Patching is urgent, but do not let it destroy evidence. Before changing a suspected system, preserve relevant logs, configuration snapshots, endpoint telemetry, and network records according to your incident-response process.
3. Hunt for signs that the application became a launcher
The most valuable hunting question is not simply Was the server scanned? It is Did the PaperCut service launch something it should not launch?
Review endpoint and application telemetry for unusual child processes from the PaperCut application, unexpected command shells or scripting engines, newly created local accounts, new services, and unexplained outbound connections. Review PaperCut logs for the vendor's listed indicators, but do not treat clean logs as proof of safety. Earlier reporting warned that attackers may delete or truncate local evidence as they progress.
Also compare the server against a known-good baseline. Look for unfamiliar class files, command files, scheduled tasks, remote-access software, or changes to service configuration. If the server had a path to directory services, elevate the investigation from application triage to identity response.
4. Identify and rotate trust material
Document every credential the server used or could access: service accounts, LDAP bind credentials, database credentials, administrator accounts, API tokens, SMTP credentials, and certificates with private keys. Prioritize identities that have broad read access or any administrative privilege.
Rotate from a clean administrative workstation after containment. If you only change passwords from the potentially compromised server, you may hand the new credentials straight back to the attacker.
Pro Tip: Treat service accounts as people with unusually broad, persistent access. Their passwords may not change for years, which makes one exposed configuration file far more valuable than an ordinary user login.
A practical containment and recovery sequence
Teams often lose time by trying to choose between patching, forensics, and credential rotation. The work should be sequenced, not treated as competing options.
- Contain exposure. Restrict public and unnecessary internal access to the PaperCut server.
- Preserve evidence. Capture logs, configurations, endpoint telemetry, and network records before cleanup where possible.
- Patch and validate. Install the vendor's current emergency release and confirm the fixed state.
- Scope identity risk. Map every account, directory connection, certificate, and integration tied to the server.
- Hunt and eradicate. Remove unauthorized accounts, persistence, remote tools, and suspicious files after evidence is secured.
- Rotate credentials. Replace affected secrets from a clean environment and revoke sessions where appropriate.
- Monitor downstream use. Watch authentication, mailbox, cloud, and remote-access logs for reuse of exposed identities.
This sequence is deliberately broader than a normal application patch cycle. When active exploitation reaches identity-connected infrastructure, restoring service is only one goal. Restoring confidence in the identities and systems that depended on it matters just as much.
What to change after the immediate response
The PaperCut case should prompt a broader review of how your organization classifies infrastructure.
First, identify applications that act as bridges between physical services and identity systems. Print management is one example, but so are badge systems, meeting-room devices, student portals, visitor-management services, scanning systems, and device-management platforms. These tools may look operationally routine while holding credentials and access to sensitive environments.
Second, make asset ownership explicit. Every such system should have a named technical owner, an identity owner, a patching expectation, a network exposure owner, and an incident-response contact. If nobody owns a service end to end, the attacker often gets the advantage.
Third, monitor privileged applications for behavior that violates their normal role. A print-management process spawning a command shell, a badge server making unusual outbound connections, or a scanner service creating administrator accounts should be high-signal events. Those detections are often more useful than trying to recognize every future exploit string.
Finally, test recovery as an identity scenario. Ask whether the team could rapidly determine which service accounts a compromised server used, rotate them without breaking operations, and see whether those identities were used elsewhere. If the answer is no, document the gap now while there is time to fix it.
Closing view
The PaperCut exploitation story is fresh because the September 5 reporting connects active attack activity to a clear outcome: credential theft from education environments. It is also useful because it exposes a wider blind spot. Systems that manage ordinary physical workflows can still be privileged identity systems in disguise.
For schools and universities, the priority is not to panic about every printer. It is to identify PaperCut servers, remove unneeded exposure, apply the current emergency fix, preserve evidence, and investigate every identity the server could have touched.
The next major credential incident may not begin at a domain controller or an SSO portal. It may begin on the server everyone forgot was responsible for printing.