SURIQ
An unauthenticated file-inclusion bug in a WooCommerce filter plugin is live on tens of thousands of stores, and the reason it is reachable without a login is the part worth your attention. HUSKY Products Filter for WooCommerce Professional, tracked as CVE-2026-92969, lets a visitor with no account reach an internal handler that will pull in and run PHP files on the server. The fix is already out in version 1.4.5. If you run this plugin, updating is today's work.
Wordfence, which assigned the CVE, rates it 8.1 on the high end of the scale and classifies it as CWE-98, PHP file inclusion. Every release through 1.4.4 carries the bug. The WordPress.org listing reports more than 80,000 active installations.
Why reaching it without a login is the whole story
The flaw sits behind an internal action the plugin exposes to render filtered product lists. On paper it has a guard: a nonce named woof_front_nonce. A nonce is meant to prove a request came from a real page rather than a forged cross-site submission. It is a cross-site-request-forgery token, not a password.
Here the plugin writes that nonce into the inline script of every shop page, according to Wordfence's advisory, so any visitor can read it straight from the page source. Once the only gate is a token the server hands out to everyone, the gate is open. That is why a high-severity file-inclusion bug on a storefront is reachable by the whole internet, not just logged-in users. The one wrinkle, reflected in the attack-complexity part of the score, is that an attacker has to grab the nonce first, which is a formality. This is the same anti-pattern behind other unauthenticated plugin bugs, like the Bookly flaw that let an anonymous visitor run scripts in the admin's browser.
What the flaw does
The vulnerable path takes a shortcode parameter, including a custom_tpl template attribute, and uses it to include a PHP file. Because that value is attacker-controlled, the include can be pointed at a file of the attacker's choosing. File inclusion here means the server runs whatever PHP is in the file it is told to load.
That has two outcomes. Any PHP already on the host can be run out of its intended context, which is enough to leak data or sidestep access checks. And where an attacker can also get a .php file onto the server, through an upload form or any other write path, the same bug becomes remote code execution. Wordfence describes exactly this escalation. It is the same unauthenticated-code-execution shape as the recent Forminator flaw that let attackers run code with no login.
Who is exposed, and how urgent
Every store running HUSKY Products Filter for WooCommerce Professional at 1.4.4 or earlier is exposed until it moves to 1.4.5. The 1.4.5 changelog credits the researcher, "crow," and Wordfence for the fix.
No public exploit for CVE-2026-92969 has surfaced yet. That is not much comfort. This plugin's template-loading code has produced file-inclusion bugs before, and at least one earlier one, CVE-2025-1661, has public proof-of-concept code on GitHub. A repeat bug in a well-trodden code path with prior working exploits tends to get weaponized fast. Treat the patch as urgent, not optional.
File-read and path-traversal flaws are not a fringe problem. On our own threat desk they are the fifth most common bug class of the past quarter, 1,063 logged, and this is the shape most of them take: a parameter that decides which file the server opens, trusted when it should not be. It is the same pattern behind campaigns that turn unpatched CMS plugins into webshells.
grep -E "admin-ajax\.php.*action=woof_draw_products" access_log grep -E "woof_draw_products.*(custom_tpl|shortcode)=.*(\.\./|\.php)" access_log find wp-content/uploads -name "*.php" -type f
The first line surfaces calls to the affected handler. The second narrows to requests whose template parameter carries path characters or a .php target. The third lists PHP files under the uploads directory, which a normal WooCommerce store should not hold. Any hit there is worth investigating.
Update to 1.4.5, then check what got included
Patching is step one: move every affected site to 1.4.5. Step two is assuming a window of exposure existed before you patched and checking it. Run the log hunts above for the internal action, look for unexpected PHP under wp-content/uploads, and if the plugin cannot be updated right away, disable it rather than leave the handler reachable. File integrity monitoring should flag new PHP files appearing in a web-writable directory; if that alert is not wired up, that is the gap to close regardless of this one plugin.