Death By A Thousand PaperCuts (PaperCut Pre-Auth RCE Chain and Patch Bypasses WT-2026-0141-0144/CVE-2026

* August 27, 2026: PaperCut published an advisory regarding a vulnerability being exploited in the wild targeting version 26.0.3, without a patch.
* The watchTowr Intel team used IOCs from the advisory to reproduce vulnerabilities.
* A Post-Auth RCE vulnerability (later identified as CVE-2026-82078) was found in the unpatched version.
* PaperCut released patch 26.0.4. Analysis of this patch enabled discovery and reproduction of other flaws, including a bypass for CVE-2026-82078 (Post-Auth RCE) and an Authentication Bypass vulnerability (CVE-2026-81578).
* A subsequent patch, 26.0.4-PO build 76508, contained fixes for the previously identified vulnerabilities.
* Analysis of the 26.0.4-PO build also revealed a new Post-Auth RCE vulnerability (CVE-2026-82077) and an Authentication Bypass vulnerability (WT-2026-0143).
* An Attack Chain combining WT-2026-0143 (Authentication Bypass) and WT-2026-0144 (CVE-2026-82077) was demonstrated to allow for Remote Code Execution (RCE) on PaperCut NG 26.0.4-PO build 76508.
* An Authentication Bypass exploit chain was demonstrated against the setup wizard pages by abusing framework logic related to how page validation handles authentication status, specifically affecting pages like SetupAdmin when `system.setup-completed` is true.
* A Post-Auth RCE vulnerability in the Scan to Fax functionality was detailed, which allows for arbitrary command execution via unverified input parameters passed through file path manipulation in the underlying process execution logic.
* The vulnerability chain exploit demonstrated a method to bypass fixes by exploiting logic flaws related to authorization checks within the Apache Tapestry 3 framework.

The narrative presents a deep dive into the fragility of patching processes and the complexity of layered security when multiple vulnerabilities exist within a single system, particularly when relying on older frameworks like Apache Tapestry 3. The core tension lies between vendor responses (issuing patches) and the actors' ability to reverse-engineer those responses to find new attack vectors—this is not merely bug hunting; it reflects a systemic failure in trust and transparency surrounding security disclosures. The shift from publicly known CVEs to internal tracking identifiers highlights a process that exists entirely outside of official remediation channels, creating a parallel reality where deep, complex exploitation chains are mapped out by independent observers.
The most striking implication is the revelation that seemingly fixed vulnerabilities can be circumvented through deeper architectural flaws—specifically, authorization logic gaps in how pages are handled (like LogonMessage and SetupWizard) and unchecked input handling during command execution. This suggests that applying patches does not inherently resolve systemic design weaknesses; rather, it merely closes specific, known doors while leaving adjacent, poorly secured pathways open, which can be re-tapped by understanding the context of other components. The exploitation chain itself is less about the individual CVEs and more about the ability to construct novel logic from disparate security artifacts, making the sequence a map of systemic insecurity rather than just a list of flaws.
What are the unseen costs associated with this dynamic? If the industry relies on layered patching, does the focus shift from fixing identified bugs to understanding and hardening the underlying architectural assumptions—like assuming that all page validation methods are globally comprehensive? If security analysis must constantly trace back through patch history to find novel bypasses, it places an unsustainable cognitive burden on defenders. The question remains: how can the velocity of vulnerability discovery by external researchers be effectively integrated into the formal security lifecycle to prevent these post-patch evasion techniques from becoming the new baseline for exploitation?
What are the unseen costs associated with this dynamic? If the industry relies on layered patching, does the focus shift from fixing identified bugs to understanding and hardening the underlying architectural assumptions—like assuming that all page validation methods are globally comprehensive? If security analysis must constantly trace back through patch history to find novel bypasses, it places an unsustainable cognitive burden on defenders. The question remains: how can the velocity of vulnerability discovery by external researchers be effectively integrated into the formal security lifecycle to prevent these post-patch evasion techniques from becoming the new baseline for exploitation?