CVE-2026-73033

CVE-2026-73033 in the Sucuri WordPress security plugin reveals a uncomfortable truth about the security tooling ecosystem: the plugins users install to protect their sites can become the most dangerous code on the installation. The vulnerability is a straightforward path traversal in the pageIntegritySubmission() function—user-supplied input concatenated directly with ABSPATH and passed to unlink(), allowing deletion of any file within the webroot. There is no subtle cryptographic weakness here. This is input validation failure in its most basic form. What makes this noteworthy is the location. Sucuri is not a forgotten plugin from an abandoned developer—it is a market-leading security product installed precisely by site operators who care about security. The paradox is structural: developers working on security software may unconsciously apply less rigorous input validation because the defensive context feels inherently protective. A function named pageIntegritySubmission, handling what appears to be scanner output, creates a false assumption that its inputs are already trusted. The CVSS 6.5 rating significantly understates the impact. Deleting wp-config.php forces WordPress reinstallation, destroying all site content and database credentials. An attacker with admin access—who may arrive through phishing or credential stuffing—can achieve complete site takeover, then use the same plugin dashboard to conceal evidence. The CVSS vector cannot capture organizational factors like backup availability or the operator's ability to diagnose what happened. This is not an isolated failure. Wordfence, All In One WP Security, and BulletProof Security have all published CVEs in similar categories—path traversal, arbitrary file deletion, privilege escalation. The WordPress security plugin ecosystem shares a common failure mode: plugins designed to secure sites operate with the same file-system access as any other plugin, while users treat them as hardened codebases. WordPress provides no enforced API-level boundary around ABSPATH. The constant is a convention, not a control. For defenders, the practical implications are: first, audit your security plugins with the same rigor you apply to any other code—do not assume that installed security tools are inherently trustworthy. Second, limit admin-role access aggressively; in the WordPress threat model, admin equals full site control anyway. Third, maintain independent backups outside the webroot—recovery from wp-config.php deletion is the only meaningful defense once exploitation succeeds. Fourth, consider whether the security plugins you run actually require admin privileges to function, and whether that requirement reflects the threat model you are trying to enforce.

Reviewed through automated stages and approved by a human before publication.