FireBox WordPress Plugin CVE-2026-76801

Exploitation requires an authenticated WordPress account with Author-level access or higher and the edit_fireboxes and publish_fireboxes capabilities. On sites that were upgraded from any version prior to 3.1.10, these capabilities are automatically granted to the Author role by Migrator::preserveCampaignRoleAccess(), meaning any registered Author (the default low-privilege content contributor role in WordPress) qualifies with no additional steps. On fresh installs of 3.1.10, Author-level access still requires a site administrator to have explicitly granted campaign editing capabilities to that role. The attack is executed over the network via the REST API (firebox_meta endpoint) with no user interaction required. The only limiting factor is possession of valid WordPress credentials at Author level or above - external unauthenticated exploitation is not possible.

The CVSS 8.8 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) accurately characterizes the threat: network-reachable, low complexity, requiring only low-privilege (Author-level) authentication, with full CIA triad compromise. The most impactful nuance is the migration-triggered privilege escalation: any WordPress site that upgraded from a pre-3.1.10 version automatically has Author-role users capable of submitting campaign conditions-meaning the effective PR:L is available to the default Author account type on a very large proportion of affected installations. The regex-bypass technique is described as trivial in the Wordfence report, suggesting low skill barrier. No CISA KEV listing and no known public POC at time of analysis, so EPSS-level exploitation probability is moderate rather than imminent mass exploitation. However, the broad Author-role entry point on migrated sites and the direct PHP execution primitive make this a high-priority patch target for any WordPress/WooCommerce site running FireBox ≤ 3.1.10.

An attacker with a registered Author account on a WooCommerce site running FireBox submits a crafted PUT request to the firebox_meta REST endpoint, embedding a PHP payload such as file_put_contents('/var/www/html/backdoor.php', '<?php system($_GET[cmd]); ?>') as a campaign condition rule value. Because file_put_contents is absent from the regex blacklist in Executer::allowedToRun(), the payload is accepted and stored without sanitization. When the campaign condition is next evaluated, the payload executes server-side, writing a web shell to the document root and granting persistent remote access.