Hand a class name to a JDBC driver loader and the loader resolves that class before it decides whether the class is a usable driver. The resolution is the sink. In the chain as documented by a dev.to breakdown crediting BleepingComputer's August 28, 2026 report, the attacker reaches the management interface unauthenticated, uses the bypass to call backend management operations and change database-related settings, then names an unwhitelisted driver class so the server loads a Java class the attacker has already placed on disk [1][5][6]. From there pc-app.exe is running commands with SYSTEM privileges [7].
The published indicators make the mechanism clear. Defenders are told to look for `jdbc:derby:memory:pwn` or "No suitable driver found" errors in `derby.log` [11], and separately for a process tree where pc-app.exe spawns `whoami`, `ver`, `tasklist` and `cmd.exe` [9]. A driver resolution that failed and a shell that ran, in the same window, points at the class load itself as the execution trigger rather than any working database connection [22]. The in-memory Derby URL means no real database has to exist for the attempt to be worth making. It is also named `pwn`, which is at least self-documenting.
This detail is what should shape your patch calendar. The writeup's preconditions require both defects at once: a reachable management interface, and an install unpatched against the authentication bypass and against the dynamic class loading [12]. Bypass vectors survived the initial fix, which is why the stated remediation is Release 2 [4]. An install that took patch one therefore still satisfies the whole precondition set [19]. The two bugs are tracked as CVE-2026-81578 and CVE-2026-82078 in PaperCut MF and NG, rated critical, and the writeup lists PaperCut's own urgent advisory alongside Huntress, The Record and SecurityWeek [2][18].
Detection guidance asks for data the attacker's housekeeping destroys. The initial check asks for version, exposure scope, patch status, the first anomaly timestamp and the source IP, with HTTP, application and audit logs preserved [15]. The chain deletes output files and `server.log` [8]. The absent file is consequently listed as an indicator in its own right [10], and the timestamp you were asked for now has to come from a log kept elsewhere, off the server [20]. Exploitation is described as looking like normal operation, with no user interaction, leaving the admin UI with nothing to show for it [17].
One caveat on transfer, because indicator lists are claims about someone else's install. pc-app.exe, SYSTEM, `.cmd` artefacts and `tasklist` describe a Windows deployment [7][9][10]. For that set to apply to yours, you need the same binary name, the same host OS and a writable `server/lib`. If you run something else, the fallback offered is WAF, load balancer and audit logs on the cloud side [16][21], and the durable signal is the one that does not depend on process names: an unauthenticated request that changes database settings.
