CVE-2026-92969: HUSKY WooCommerce Filter RCE Vulnerability

CVE-2026-92969 Overview

The HUSKY – Products Filter for WooCommerce Professional plugin for WordPress contains a Local File Inclusion (LFI) vulnerability in all versions up to and including 1.4.4. The flaw resides in the handling of the shortcode parameter, which allows unauthenticated attackers to include and execute arbitrary .php files on the server. Exploitation can bypass access controls, disclose sensitive data, or achieve remote code execution when combined with file upload capabilities. The plugin's only access control is a nonce check against woof_front_nonce, which is publicly emitted into inline JavaScript on every front-end page and therefore obtainable by any site visitor.

Critical Impact
Unauthenticated attackers can include and execute arbitrary PHP files on affected WordPress sites, leading to code execution and full site compromise.

Affected Products

HUSKY – Products Filter for WooCommerce Professional plugin — all versions up to and including 1.4.4
WordPress installations running the vulnerable plugin
WooCommerce storefronts that expose the plugin's front-end shortcodes

Discovery Timeline

2026-09-22 - CVE-2026-92969 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-92969

Vulnerability Analysis

The vulnerability is classified as Local File Inclusion (LFI) and mapped to [CWE-98] Improper Control of Filename for Include/Require Statement in PHP Program. The plugin accepts a shortcode parameter through a front-end request handler and passes attacker-controlled input into a PHP include/require path without adequate sanitization or allow-list validation. Because the request is gated only by a nonce that is publicly rendered into the page markup, any anonymous visitor can retrieve the nonce and issue the vulnerable request. Successful exploitation yields execution of arbitrary PHP files present on the server, including uploaded media or log files under attacker influence.

Root Cause

The root cause is the use of unsanitized user input in a PHP file inclusion sink combined with an insufficient authorization model. The woof_front_nonce value is emitted in inline JavaScript on every front-end page, effectively neutralizing its value as an anti-CSRF token for authenticated actions. The plugin then treats a valid nonce as authorization to include a caller-specified file path. See the WordPress Plugin Code Review at index.php line 1044 and the related sink at line 2677 for the vulnerable code paths.

Attack Vector

An attacker first requests any public page of the WordPress site to harvest the woof_front_nonce value from inline JavaScript. The attacker then issues an unauthenticated HTTP request to the plugin's AJAX endpoint with a crafted shortcode parameter that references an arbitrary .php file on disk. The PHP interpreter includes and executes the target file within the plugin's execution context. In environments that permit uploads of files interpreted as PHP, the attacker chains the LFI with an upload to obtain remote code execution.

// No verified public exploit code is available.
// Refer to the Wordfence advisory and plugin source references for technical details.

Detection Methods for CVE-2026-92969

Indicators of Compromise

Unauthenticated POST or GET requests to WordPress AJAX endpoints containing a shortcode parameter with path traversal sequences or absolute file paths
Web server access logs showing repeated requests referencing woof_front_nonce followed by requests including .php file paths
Unexpected PHP files created in wp-content/uploads/ or plugin directories, particularly with recent modification timestamps
Outbound network connections initiated by the PHP-FPM or web server process to unfamiliar hosts following suspicious plugin requests

Detection Strategies

Inspect HTTP request bodies for the shortcode parameter combined with characters such as ../, %2e%2e, or references to files outside expected plugin directories
Correlate front-end page loads that retrieve woof_front_nonce with subsequent AJAX calls invoking plugin actions from the same client
Alert on PHP file writes within uploads directories where PHP execution is not expected
Baseline normal request patterns for the woocommerce-products-filter plugin and flag deviations that reference filesystem paths

Monitoring Recommendations

Enable verbose logging on the WordPress AJAX endpoint admin-ajax.php and any plugin-specific handlers
Monitor process creation and file access events on the web server host for the PHP interpreter accessing files outside the WordPress document root
Ingest web access logs and WordPress audit logs into a centralized analytics platform for cross-source correlation of nonce harvesting and inclusion attempts

How to Mitigate CVE-2026-92969

Immediate Actions Required

Update the HUSKY – Products Filter for WooCommerce Professional plugin to a version later than 1.4.4 as soon as the vendor publishes a fixed release
If a patched version is unavailable, deactivate and remove the plugin from all affected WordPress sites
Audit wp-content/uploads/ and plugin directories for unauthorized .php files and remove any that are not part of legitimate deployments
Rotate WordPress administrator credentials and secret keys on any host that exhibited signs of exploitation

Patch Information

The vendor commit history is tracked in the WordPress Plugin Changeset. Administrators should consult the Wordfence Vulnerability Report for the current fixed version and detailed remediation guidance.

Workarounds

Deploy a Web Application Firewall (WAF) rule that blocks requests to the plugin's AJAX endpoints when the shortcode parameter contains path traversal sequences or .php references
Configure the web server to deny PHP execution within wp-content/uploads/ and other writable directories
Restrict access to plugin endpoints to authenticated administrators via server-level access controls until a patch is applied

bash

# Example nginx directive to deny PHP execution in uploads
location ~* /wp-content/uploads/.*\.php$ {
    deny all;
    return 403;
}