PaperCut NG and PaperCut MF administrators are facing an unusually urgent security incident. On August 27, 2026, PaperCut Software disclosed that attackers were actively exploiting a vulnerability affecting its NG and MF print-management platforms.
The vendor confirmed customer incidents and instructed organizations with internet-accessible PaperCut Application Servers to immediately restrict web access to trusted IP addresses. By August 28, PaperCut had also released emergency patches for version 25 and version 26 installations.
There is, however, an important detail behind the current surge in searches for PaperCut CVE:
The vulnerability being actively exploited in August 2026 does not yet have a publicly disclosed CVE identifier.
That distinction matters.
CVE-2026-8793 and CVE-2026-8794 were disclosed earlier in August and affect PaperCut authentication behavior, but they are separate vulnerabilities. PaperCut stated at the time that it had no evidence those issues were being exploited.
The newly observed attacks instead involve another vulnerability that PaperCut and independent security researchers are still analyzing.
Huntress has already substantially expanded the public understanding of the flaw. Its researchers report reproducing a pre-authentication remote configuration takeover that can be chained into remote code execution against an unpatched PaperCut NG 25.0.11 system.
The company has also observed exploitation in real customer environments.
For defenders, this should therefore be treated as an active intrusion problem, not simply another vulnerability-management ticket.
PaperCut CVE Situation at a Glance
| 항목 | Current status |
|---|---|
| Products | PaperCut NG and PaperCut MF |
| 익스플로잇 | Confirmed active exploitation |
| New vulnerability CVE | Not publicly disclosed as of August 28, 2026 |
| Authentication required | Pre-auth exploitation reproduced |
| Potential impact | Configuration takeover and remote code execution |
| 영향을 받는 범위 | Current advisory broadly covers NG/MF deployments |
| Emergency patches | Available for v25 and v26 |
| v24 patch | Not yet available at initial disclosure |
| Highest-risk exposure | Internet-accessible Application Servers |
| Immediate response | Restrict exposure, investigate, patch |
The important point is that administrators should not assume a relatively recent PaperCut version is safe simply because their vulnerability scanner shows no critical PaperCut CVE.
The vulnerability currently being exploited exists ahead of the normal CVE-driven vulnerability-management pipeline.
What Happened to PaperCut NG and MF?
PaperCut published its urgent advisory on August 27 after its security response team began investigating active exploitation against PaperCut NG and PaperCut MF.
This was not a vulnerability discovered solely during internal testing.
The vendor confirmed that real customers had already been affected.
Forensic information from impacted environments helped PaperCut engineers reproduce the underlying vulnerability and develop emergency mitigations and patches.
The rough sequence therefore looks like this:
Unknown vulnerability
↓
Real-world exploitation
↓
Customer compromise
↓
Incident response
↓
Vendor reproduction
↓
Emergency mitigation
↓
Emergency patch
That sequence is fundamentally different from the more familiar vulnerability lifecycle:
Researcher finds bug
↓
Vendor notified
↓
Patch developed
↓
CVE assigned
↓
Disclosure
↓
Attackers begin scanning
In the current PaperCut case, attackers appear to have been operating before defenders had a CVE number to track.
That is what makes the incident particularly dangerous.
Why Searching for a PaperCut CVE Can Be Misleading
Most enterprise vulnerability-management workflows are organized around standardized identifiers.
The workflow often looks like this:
CVE
↓
CVSS
↓
Affected product/version
↓
Scanner signature
↓
Ticket
↓
Patch
The active PaperCut vulnerability currently breaks that model.
There is no public CVE identifier yet.
That means organizations depending heavily on NVD feeds, CVE inventories, CVSS thresholds or scanner signatures may not receive the kind of automated critical alert they normally expect.
Yet the vulnerability is already operationally severe.
PaperCut has acknowledged real attacks.
Independent researchers have reproduced exploitation.
Emergency patches have been released.
Those facts matter more than whether the vulnerability has already received a standardized identifier.
A CVE is metadata.
It is not what makes a vulnerability exploitable.
Technical Analysis of the PaperCut Vulnerability

PaperCut has deliberately limited some technical details while exploitation is ongoing, but Huntress has published enough information to understand the broad failure mode.
At a high level, the issue appears related to authorization logic inside the PaperCut web application.
A specially constructed request can reportedly create a mismatch between the application page used for an authorization decision and the sensitive component or action that actually executes.
Conceptually, the normal security model should look like:
Incoming request
↓
Identify requested action
↓
Determine required privileges
↓
Authenticate user
↓
Authorize user
↓
Execute action
A vulnerable flow can instead behave more like:
Incoming malicious request
↓
Application evaluates one page/context
↓
Authorization appears acceptable
↓
Different privileged action is triggered
↓
Sensitive configuration becomes reachable
Once an unauthenticated attacker can cross that security boundary, seemingly administrative configuration functionality becomes attacker-controlled.
That can be far more dangerous than it initially sounds.
Why Configuration Takeover Can Become RCE
A vulnerability does not need a direct operating-system command injection endpoint to become remote code execution.
Modern application configuration often controls:
- database connections;
- plugin loading;
- external resources;
- scripts;
- templates;
- drivers;
- file locations;
- network shares;
- authentication integrations.
If an attacker can influence one of those mechanisms strongly enough, configuration control can become execution control.
The simplified PaperCut attack chain therefore becomes:
Unauthenticated attacker
↓
Authorization bypass
↓
Sensitive configuration modification
↓
Attacker-controlled resource
↓
Application loads attacker-controlled content
↓
Remote code execution
This is an important distinction for defenders.
A finding labeled something like “configuration manipulation” may sound less urgent than “command injection.”
In reality, both can ultimately produce the same result.
The Role of Derby and Remote Resources
Huntress’ research also identified exploitation behavior connected with Derby database functionality.
Researchers demonstrated an attack path involving an attacker-controlled network resource and PaperCut database-related configuration.
The exact exploit implementation may evolve as researchers and attackers experiment with the vulnerability, so defenders should avoid building detection rules around only one payload.
The more important architectural behavior is:
PaperCut server
↓
Attacker changes trusted configuration
↓
Application accesses attacker-controlled resource
↓
Malicious code becomes reachable
↓
Execution occurs inside trusted server context
This type of exploitation can be especially dangerous because the malicious action is being performed by a legitimate application process.
From the operating system’s perspective, PaperCut itself may be the process performing the suspicious activity.
Why pc-app.exe Matters
On Windows PaperCut deployments, defenders should pay close attention to activity originating from:
pc-app.exe
The existence of pc-app.exe is obviously not malicious.
It is part of PaperCut.
The detection opportunity comes from its behavior.
Consider the following process tree:
pc-app.exe
|
+-- cmd.exe
|
+-- whoami.exe
or:
pc-app.exe
|
+-- powershell.exe
|
+-- encoded payload
That should immediately raise questions.
Security teams should investigate whether pc-app.exe suddenly begins spawning:
cmd.exe
powershell.exe
pwsh.exe
wscript.exe
cscript.exe
rundll32.exe
regsvr32.exe
Again, none of these binaries is inherently malicious.
The suspicious characteristic is the unexpected parent-child relationship.
A print-management Application Server should not normally begin launching interactive reconnaissance and scripting tools following requests from an anonymous internet client.
Observed Post-Exploitation Commands
Huntress reported exploitation attempts in multiple customer environments.
During observed activity, attackers executed simple reconnaissance commands including:
whoami
ver
and:
whoami
ver
tasklist
These commands may look primitive, but they make perfect sense immediately after obtaining remote code execution.
An attacker needs to determine:
Did exploitation succeed?
Which account is executing?
What Windows version is this?
What security software is running?
What processes exist?
What should I target next?
That is precisely what 누가미, ver 그리고 tasklist provide.
The commands therefore represent much more than generic system administration.
In the right process context, they are evidence of post-exploitation validation.
Why SYSTEM-Level Execution Is Serious
PaperCut servers are particularly interesting because the Application Server can operate with significant operating-system privileges.
Huntress demonstrated behavior in which attacker-controlled execution could occur from the PaperCut Application Server context and result in high-privilege execution.
On Windows, a process executing as SYSTEM has extraordinary control over the host.
Once an attacker reaches this position, the original PaperCut vulnerability may become almost irrelevant.
The attack has entered normal post-exploitation territory.
Possible attacker objectives can include:
Credential discovery
↓
Persistence
↓
Internal reconnaissance
↓
Lateral movement
↓
Privilege expansion
↓
Domain compromise
↓
Data theft or ransomware
Not every compromised PaperCut server will experience all of these stages.
But incident responders should investigate them.
Indicators of Compromise
PaperCut has published several preliminary indicators that administrators can use during incident response.
Organizations should pay particular attention to unusual PaperCut server log events, suspicious endpoint activity and unexpected changes to server.log.
One indicator highlighted by PaperCut is:
ERROR No suitable driver found for jdbc:no:x
Another is:
ERROR DatabaseUtils - Database error looking up cardID: VALUES CAST
Researchers have additionally observed Derby-related artifacts such as:
DB URL: jdbc:derby:memory:pwn
These indicators can be useful starting points.
They must not become the only compromise test.
A server that does not contain these strings is not automatically clean.
Attackers can change payloads.
Logs can rotate.
Logs can be deleted.
Attack attempts may fail at different points.
Different exploit implementations may leave different artifacts.

Check for Deleted or Truncated Logs
One particularly important indicator is unexpected modification of PaperCut logging.
Investigators should check whether:
server.log
has been:
- deleted;
- truncated;
- unexpectedly recreated;
- modified outside normal operational patterns;
- missing from a period when PaperCut was actively running.
Log destruction is itself useful evidence.
It may indicate an attacker attempting to remove traces after exploitation.
This also illustrates why organizations should never rely solely on local application logs.
A mature detection architecture should combine:
PaperCut logs
+
EDR telemetry
+
Reverse-proxy logs
+
Firewall logs
+
DNS logs
+
Network telemetry
+
Central SIEM
An attacker who compromises an application may be able to modify local application logs.
Deleting logs that have already been shipped into an external SIEM is significantly harder.
Hunting PaperCut Logs
Administrators can begin searching known log artifacts using PowerShell.
예를 들어
Get-ChildItem -Path "C:\Program Files\PaperCut*" -Recurse -Filter "*.log" -ErrorAction SilentlyContinue |
Select-String -Pattern "jdbc:no:x","VALUES CAST","jdbc:derby:memory:pwn"
This should be treated as an investigative starting point rather than a definitive compromise scanner.
Installation paths vary.
Logs may have rotated.
Attackers may leave different artifacts.
Security teams should combine log analysis with endpoint and network telemetry.
EDR Hunting for Suspicious Process Trees
One of the strongest defensive approaches is to hunt for unexpected children of the PaperCut Application Server process.
Conceptually:
Parent:
pc-app.exe
Child:
cmd.exe
powershell.exe
pwsh.exe
wscript.exe
cscript.exe
rundll32.exe
regsvr32.exe
The detection logic should incorporate:
- parent process;
- child process;
- command line;
- execution timestamp;
- user context;
- outbound network connection;
- file creation;
- subsequent processes.
예를 들어
pc-app.exe
↓
cmd.exe /c whoami
is significantly more suspicious than simply detecting whoami.exe somewhere in the environment.
Context turns a common administrative utility into meaningful security telemetry.
Hunt for Discovery Commands
Because attackers have already been observed performing system discovery, defenders should search historical EDR telemetry for commands such as:
whoami
hostname
ver
systeminfo
tasklist
ipconfig
net user
net group
nltest
quser
qwinsta
These commands appear in legitimate administration every day.
Therefore a rule such as:
Detect every execution of whoami.exe
would generate significant noise.
A better analytic is:
PaperCut process
↓
Command interpreter
↓
System discovery command
That relationship is much more valuable.
Watch for Unexpected SMB Traffic
Another potentially important detection opportunity is outbound SMB.
Researchers demonstrated an exploitation route involving attacker-controlled network resources.
That creates a useful behavioral question:
Why is a PaperCut Application Server initiating an SMB session toward an unknown external host?
In many organizations the answer should be:
It should not.
A network architecture allowing unrestricted SMB traffic from internal application servers to the public internet provides attackers with unnecessary opportunities.
Security teams should consider blocking outbound SMB at the internet perimeter unless there is a documented business reason.
That simple control can interfere with entire classes of exploitation and credential-relay behavior.
Internet Exposure Is the Immediate Risk
PaperCut’s most urgent mitigation is straightforward:
Do not expose the PaperCut Application Server web interface directly to the internet unless absolutely necessary.
Organizations should restrict access to trusted administrative networks, VPN infrastructure or controlled access proxies.
A safer architecture looks like:
Internet
|
X
|
VPN / ZTNA / Firewall
|
Trusted network
|
PaperCut NG/MF
rather than:
Internet
|
PaperCut NG/MF
This matters even after the current vulnerability is patched.
Removing unnecessary public exposure reduces the organization’s risk from the next PaperCut vulnerability as well.
Patch Availability
PaperCut released emergency fixes for version 25 and version 26 shortly after public disclosure.
Administrators should obtain the packages directly from PaperCut and validate the installer hashes against those published in the vendor advisory.
The company has characterized these packages as emergency patches.
That wording is significant.
Emergency security releases may not go through exactly the same validation and rollout process as routine stable releases.
Organizations should therefore:
- prioritize security deployment;
- test critical integrations where possible;
- monitor PaperCut behavior after upgrading.
This is a situation where the risks of delaying remediation must be weighed against the risks of deploying an emergency release.
For internet-exposed servers under active exploitation, delaying remediation is difficult to justify.
Card and ID Database Compatibility Warning
Organizations using external database lookups for Card or ID authentication should pay particular attention to the emergency update.
PaperCut has warned that SQL statements containing keywords such as:
EXEC
EXECUTE
CALL
may no longer be permitted under the hardened behavior.
This could affect custom authentication or badge workflows.
Administrators should therefore review any external Card/ID database integration when rolling out the patch.
The operational issue is real.
But it should not become an excuse for leaving an internet-exposed, actively exploitable server unpatched.
Is the Active PaperCut Attack CVE-2026-8793?
No.
CVE-2026-8793 is a separate vulnerability disclosed earlier in August 2026.
It involves insufficient protection against repeated authentication attempts.
In affected scenarios, attackers may be able to conduct excessive login attempts without adequate rate limiting or related protections.
PaperCut addressed that issue in newer releases.
It is not the vulnerability currently associated with the newly disclosed pre-authentication RCE activity.
Security articles that simply label the August 27 exploitation as CVE-2026-8793 are therefore conflating separate issues.
Is It CVE-2026-8794?
No.
CVE-2026-8794 is also distinct.
That vulnerability involves an observable timing discrepancy associated with authentication behavior.
Timing differences can potentially allow a remote attacker to distinguish valid usernames from invalid ones.
That is a security issue, but it is fundamentally different from the authorization/configuration vulnerability involved in the current active exploitation.
CVE-2026-8794 should therefore not be used as the identifier for the new campaign.
CVE-2023-27350 and the 2023 PaperCut Attacks
The most important historical comparison is CVE-2023-27350.
That vulnerability affected PaperCut NG and PaperCut MF and allowed unauthenticated attackers to bypass authentication and execute code remotely.
CISA and the FBI issued a joint advisory after malicious actors began exploiting vulnerable PaperCut servers in 2023.
The vulnerability was ultimately used by multiple threat actors and demonstrated why publicly exposed print-management infrastructure could become an attractive initial-access target.
The historical affected branches included:
| Major version | Vulnerable releases reported in the 2023 campaign |
|---|---|
| PaperCut 19 | 8.0.0–19.2.7 |
| PaperCut 20 | 20.0.0–20.1.6 |
| PaperCut 21 | 21.0.0–21.2.10 |
| PaperCut 22 | 22.0.0–22.0.8 |
CVE-2023-27350 was also added to CISA’s Known Exploited Vulnerabilities Catalog.
The 2023 incident provides an important warning for the 2026 campaign:
Once reliable exploitation of a PaperCut server becomes broadly available, exploitation can spread extremely quickly.
CVE-2023-27350 vs the 2026 PaperCut Zero-Day
| Characteristic | CVE-2023-27350 | August 2026 vulnerability |
|---|---|---|
| 제품 | PaperCut NG/MF | PaperCut NG/MF |
| Remote attack | 예 | 예 |
| Pre-auth attack | 예 | Reproduced |
| RCE potential | 예 | Reproduced |
| Active exploitation | 예 | 예 |
| Public CVE | CVE-2023-27350 | Not yet publicly assigned |
| Internet exposure risk | 높음 | 높음 |
| Emergency response needed | 예 | 예 |
The biggest operational difference is visibility.
During the mature phase of the 2023 incident, defenders could build policies around:
CVE-2023-27350
In the current campaign, the vulnerability-management ecosystem is still catching up.
Why PaperCut Servers Are Attractive Targets
PaperCut is not simply a webpage controlling printers.
Enterprise print-management software can occupy an unusually trusted position inside corporate networks.
It may interact with:
- Active Directory;
- LDAP;
- authentication systems;
- print servers;
- employee endpoints;
- databases;
- multifunction printers;
- network shares;
- administrative accounts.
That makes a PaperCut Application Server potentially valuable as an initial foothold.
If attackers obtain high-privilege execution, they may immediately begin searching for credentials, accessible systems and lateral-movement opportunities.
The intrusion may evolve from:
Internet
↓
PaperCut
into:
Internet
↓
PaperCut
↓
Internal credentials
↓
Adjacent servers
↓
Directory infrastructure
Incident responders therefore need to determine whether the PaperCut server was merely attacked or actually became the first stage of a larger intrusion.
What to Do If Your PaperCut Server Was Internet-Facing
If a PaperCut Application Server was publicly reachable during the exploitation window, organizations should treat that exposure as a reason to investigate.
Restrict external access
Remove direct internet reachability immediately.
Use firewall rules, VPN access, ZTNA or trusted source-IP allowlists.
증거 보존
Collect:
- PaperCut logs;
- current configuration;
- EDR process telemetry;
- network connections;
- reverse-proxy logs;
- firewall events;
- DNS records;
- file creation timestamps.
Do this before unnecessary cleanup destroys evidence.
Hunt known indicators
Search for the current JDBC-related strings and abnormal changes to server.log.
Examine pc-app.exe
Review historical child processes, command lines and network activity.
Search for post-exploitation activity
Look for:
- discovery commands;
- persistence;
- new services;
- scheduled tasks;
- new accounts;
- credential dumping;
- remote management;
- lateral movement.
Install the emergency patch
Apply the correct PaperCut update from the vendor.
Rotate credentials where necessary
If compromise is established or credentials may have been exposed, determine which credentials were accessible from the PaperCut host and rotate them according to risk.
Continue monitoring
Patching removes the initial vulnerability.
It does not remove attacker persistence established before remediation.
Why Traditional Vulnerability Scanners Can Miss This
Traditional scanners largely operate on already-known vulnerability knowledge.
The pipeline usually looks like:
Vendor disclosure
↓
CVE assigned
↓
Affected versions mapped
↓
Scanner plugin developed
↓
Customer scan
Zero-day exploitation looks different:
Attacker discovers or obtains exploit
↓
Victims compromised
↓
Researchers investigate
↓
Vendor reproduces bug
↓
Patch released
↓
CVE arrives later
↓
Scanner coverage follows
This creates a dangerous interval.
During that period:
The vulnerability is exploitable, but the vulnerability-management system may not know what to call it.
That is why continuous exposure monitoring, behavioral detection and threat intelligence matter.
PaperCut Exposure Validation
Security teams assessing the current risk should answer five questions.
Is the PaperCut server publicly reachable?
확인:
- firewall rules;
- public IP addresses;
- cloud security groups;
- reverse proxies;
- load balancers;
- DNS records.
Which PaperCut version is actually running?
Verify the live system.
Do not rely exclusively on stale CMDB information.
Was it exposed before the patch?
Current segmentation does not tell you whether the server was reachable yesterday.
Historical firewall and proxy logs do.
Did exploitation happen?
Search endpoint, application and network telemetry.
Did the attacker move elsewhere?
Inspect internal authentication and lateral-movement behavior after suspicious PaperCut activity.
This is the difference between vulnerability management and incident response.
Frequently Asked Questions
What is the latest PaperCut CVE?
There are two different concepts here.
CVE-2026-8793 and CVE-2026-8794 were publicly disclosed PaperCut vulnerabilities in August 2026.
However, they are not the vulnerability associated with the current active exploitation campaign.
The newly exploited issue had not yet received a publicly disclosed CVE identifier as of August 28, 2026.
Is PaperCut being actively exploited?
Yes.
PaperCut has confirmed real customer incidents, and external researchers have separately observed exploitation activity.
Does the vulnerability allow remote code execution?
Independent researchers have reproduced a pre-authentication chain capable of reaching remote code execution.
Is authentication required?
The publicly reproduced attack path is pre-authentication.
That greatly increases the danger of internet exposure.
Are PaperCut NG servers affected?
Yes.
Are PaperCut MF servers affected?
Yes.
Is a patch available?
Emergency patches have been released for current v25 and v26 deployments.
Administrators should consult the live PaperCut advisory for the latest package and version information.
Is CVE-2026-8793 the active exploit?
No.
It is a different PaperCut vulnerability.
Is CVE-2026-8794 the active exploit?
No.
It is also separate.
Is this the same as CVE-2023-27350?
No.
CVE-2023-27350 is the historical PaperCut vulnerability heavily exploited in 2023.
The 2026 vulnerability is a new security issue.
If I cannot find any IoCs, is my server safe?
No.
Absence of currently known indicators does not prove that exploitation did not occur.
Security teams should use multiple independent telemetry sources.
The Bigger Security Lesson
The current PaperCut incident highlights a structural problem in modern vulnerability management.
Defenders often think in terms of:
CVE → CVSS → Scanner → Ticket → Patch
Attackers think in terms of:
Can I exploit it?
Those are not the same timeline.
An attacker does not need NVD to publish a vulnerability record.
They do not need a CVSS score.
They do not need CISA KEV.
They do not need a scanner plugin.
They only need the exploit to work.
The PaperCut campaign demonstrates why defenders need systems capable of reacting to evidence of exploitation, rather than waiting exclusively for standardized vulnerability metadata.
결론
The latest PaperCut CVE incident is unusual because the vulnerability creating the emergency does not yet have a public CVE identifier.
PaperCut NG and PaperCut MF servers are facing confirmed active exploitation of a newly discovered vulnerability. Independent researchers have demonstrated that the weakness can be abused before authentication and chained into remote code execution.
Organizations operating PaperCut should therefore focus on four immediate priorities:
Restrict exposure. Preserve evidence. Investigate compromise. Patch aggressively.
Security teams should also avoid confusing the new vulnerability with CVE-2026-8793, CVE-2026-8794 or the historic CVE-2023-27350.
The broader lesson is simple:
A vulnerability does not become dangerous when it receives a CVE number.
Sometimes attackers are already executing code while the security industry is still deciding what to call the bug.

