PaperCut attacks show why patching is not the end of an incident

Organisations affected by attacks on PaperCut’s print management software have faced a more complicated task than applying a single patch.

PaperCut disclosed in August that attackers were exploiting two vulnerabilities affecting PaperCut NG and MF. Chained together, the flaws could allow attackers to bypass authentication, change system configurations and execute code on the application server.

Three emergency patches followed as the investigation developed. Customers that installed the first or second were later told to apply the third, which added further protections and corrected problems affecting SAML authentication and legacy Microsoft SQL Server drivers. Rapid7 found that the first patch could be bypassed.

PaperCut has since issued fully tested maintenance releases that replace the emergency builds.

The case shows why urgent patching must be treated as both a security response and an operational change. Fixes issued outside normal release cycles can disrupt authentication, databases and older integrations. Risk teams should identify these dependencies, test critical services after installation and prepare fallback arrangements.

Patching also cannot establish whether attackers accessed a system before the fix was applied. Organisations must review logs and indicators of compromise, investigate suspicious activity and rebuild affected servers where necessary.

Procurement teams should examine how suppliers communicate changing advice, support legacy environments and assist customers when emergency remediation disrupts essential services. A patch may close the vulnerability, but validation and investigation are still needed before the incident can be considered over.