CVE-2026-112866: WBW Product Filter Unauth Blind SQLi - Floor 3.4.7

CVE-2026-112866 is Patchstack’s name for an unauthenticated blind SQL injection in Product Filter by WBW (woo-product-filter) through 3.4.6. They score it 9.3 critical (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L). CWE-89. CVE state PUBLISHED. NVD vulnStatus Deferred. datePublished 2026-10-24T08:00:11.483Z. Patchstack datePublic 2026-10-22T07:29:42.000Z. Finder: Yuto Hyakumoto | Patchstack Bug Bounty Program. Floor: 3.4.7.[1][2]

The wordpress.org plugin API this morning returned version 3.4.7, active_installs 50000 (the directory’s 50k bucket), last updated 2026-10-20 5:08pm GMT, tested to 7.1.3, requires WP 5.0. Contributors: woobewoo. Homepage: https://woobewoo.com/product/woocommerce-filter/. Readme stable tag 3.4.7. Bootstrap file: woo-product-filter.php.[4][5]

The CNA affected.vendor string is WPFactory. The wordpress.org listing and 3.4.7 tag still say WBW Plugins / woobewoo. We did not pull a merger filing. Inventory the slug woo-product-filter, not the brand on the icon.[1][5]

Vendor changelog 3.4.7 (dated 20/10/2026 in readme.txt):

“Fixed an SQL injection vulnerability in product filters.”
“Fixed an unauthenticated information disclosure vulnerability in the frontend product query.”
“Improved output escaping and AJAX response handling in the frontend filter request.”
JSON_HEX_* flags on WooBeWoo_PF_Response::ajaxExec().[4]

Only the SQLi has a CVE ID we pulled for this release. Treat the info-disclosure bullet as vendor changelog, not as CVE-2026-112866.[1][4]

What it is

This is CWE-89 in a WooCommerce product-filter plugin, not WordPress core, not WooCommerce core, and not PHP2Shell.[1][2]

Patchstack’s CNA text: improper neutralization of SQL specials in Product Filter by WBW allows Blind SQL Injection, package woo-product-filter, collection https://wordpress.org/plugins, affected from 0 through 3.4.6, unaffected at 3.4.7. Vector is unauthenticated (PR:N), no user click (UI:N), scope changed, confidentiality high, integrity none, availability low.[1][2]

The vendor does not name a request parameter in 3.4.7. Older WBW SQLi rows (2025 filtersDataBackend, etc.) are different CVE IDs. Do not copy those parameter names onto 112866. We did not dump the 3.4.6 query builder.[1][4]

3.4.6 is not a clean build. That tag already “Restricted product query arguments sent from the browser.” The CNA still lists through 3.4.6. Floor is 3.4.7.[1][4]

The CNA product is the wordpress.org package. It does not name a PRO zip. Do not assume WooBeWoo / WPFactory PRO is in or out of this ID without a Pro advisory - we did not inventory Pro source.[1]

How serious

A 9.3 with C:H and I:N is “the database can be read,” not “eval as www-data.” Blind SQLi is how you extract rows without seeing query output in the page. Hashes, emails, wp_options secrets, other tenants’ tables on a shared prefix - that is the confidentiality claim. It is not a claimed unauth RCE, plugin upload, or edit_user() chain.[1][2]

CISA’s SSVC row on the NVD object (timestamp 2026-10-24T14:41:21.723387Z, role CISA Coordinator): exploitation: none, automatable: yes, technicalImpact: partial. That is CISA’s coordinator assessment on the NVD record, not a KEV listing.[2]

This CVE is not in CISA KEV as of catalog 2026.10.26 (dateReleased 2026-10-26T22:24:24.6101Z, 1758 entries). Newest dateAdded on that dump: 26 Oct PHP2Shell (CVE-2026-109618 / 109619). Absence from KEV is not a clean bill of health; it means CISA has not listed confirmed in-the-wild under that program.[3]

NVD vulnStatus is Deferred. No NVD-assigned 3.1 of its own on the object we fetched - the 9.3 is Patchstack’s, type Secondary (audit@patchstack.com). NVD lastModified 2026-10-26T13:41:11.497.[2]

Who is affected

In scope, per the CNA affected block:[1]

Package woo-product-filter, product name Product Filter by WBW, versions 0 through 3.4.6.
Any public WooCommerce shop that loads the filter on a catalog / shop / Elementor page. The vector is PR:N. The CNA does not require a login, a nonce, or an admin session.

Out of scope unless you have a separate advisory:

Sites already on 3.4.7 (API version this morning is 3.4.7).[5]
WooCommerce core, WordPress core, PHP itself.
Other filter plugins (woocommerce-products-filter, YITH, etc.). Different slugs.
A PRO build that is not the wordpress.org woo-product-filter package - unlisted, not “safe.”

wordpress.org version stats this morning (major.minor buckets only): 3.4 51.37%, 3.1 12.59%, 3.0 8.01%, 2.7 5.97%, other 22.06%. The 3.4 bucket includes both 3.4.6 (affected) and 3.4.7 (current); we cannot split it from that table.[6]

What to do now

Inventory the slug, not a “product filter” screenshot.

# one site
wp plugin get woo-product-filter --field=version --path=/home/USER/public_html
wp plugin list --name=woo-product-filter --fields=name,status,version --path=/home/USER/public_html

# cPanel box, every account (read-only)
find /home -path '*/wp-content/plugins/woo-product-filter/woo-product-filter.php' 2>/dev/null \
  | while read -r f; do
      ver=$(awk -F': ' '/^[[:space:]]*\*?[[:space:]]*Version:/{print $2; exit}' "$f")
      echo "$ver  $f"
    done

Ship 3.4.7. That is what wordpress.org is serving. Do not leave 3.4.6 “because 3.4.6 already restricted query arguments.”[1][4][5]

wp plugin update woo-product-filter --path=/home/USER/public_html
wp plugin get woo-product-filter --field=version --path=/home/USER/public_html   # want 3.4.7

If you cannot update today: deactivate. A WAF rule is not a version bump. The plant is the filter AJAX / frontend product query, not wp-login.php.[1][4]

wp plugin deactivate woo-product-filter --path=/home/USER/public_html

After the bump, this patch does not rewind a dump that already left. If you have reason to hunt: unexpected SELECT volume against wp_users / wp_usermeta / wp_options from the web user around 20-24 Oct, new admin accounts you did not create, PHP files under wp-content that were not part of a deploy. Presence of a new admin is a hunt target for any WP incident, not a fingerprint unique to this CVE. Rotate WordPress salts if you find a foothold. We are not publishing a payload.
Unsupported / frozen lines. The CNA defaultStatus is unaffected except ≤ 3.4.6. There is no 3.1.x / 2.7.x patched build in the record we pulled. Jump a frozen site through staging, or remove the plugin.[1][6]

Compromise signs

The published class is unauth blind SQLi → claimed DB read. Hunt for, do not treat as proof:[1][2]

Filter AJAX (admin-ajax.php / plugin REST) with odd AND SLEEP / stacked-query looking query strings in access logs around 20-24 Oct. We did not verify a parameter name.
MySQL slow log entries from the site’s PHP user you cannot match to a shopper session.
New WordPress administrators you did not create.
PHP files under wp-content dated in the same window that were not part of a deploy.

Absence is not proof of cleanliness. We did not publish a Nuclei template and we did not send a probe.

FAQ

Is this PHP2Shell? No. PHP2Shell is CVE-2026-109618 / 109619 in PHP itself, and those two IDs are on CISA KEV as of 2026-10-26. This ID is WBW’s filter plugin. Patch PHP and this plugin if you are behind on both.[1][3]

Do I have to be logged in? CNA / NVD vector is PR:N.[1][2]

Does this give RCE? Not in the CNA. They typed Blind SQL Injection. Integrity is none. Do not upgrade this to “unauth RCE” without a source that says so.[1][2]

Does this give root on the box? No. Even a changed-scope (S:C) read of MySQL is still the web-server user’s database grants, not a claimed KVM or panel root.[1][2]

Is WooCommerce itself vulnerable under this ID? Not in the CNA affected product list. Patch woo-product-filter.[1][5]

Is 3.4.6 enough? No. 3.4.6 is the last affected version Patchstack listed. Floor 3.4.7.[1][4]

The shop does not put a filter on the home page. Inventory the version anyway. The CNA version range does not shrink because you “don’t think you use filters.”[1]

Honesty / What we could not verify

We did not exploit this. No filter request was sent. No SLEEP() was issued. No row was extracted.
We did not prove a parameter. Patchstack says blind SQLi; the vendor says “in product filters.” We did not reconstruct the 3.4.6 SQL.
50,000 is wordpress.org active_installs this morning, not a census we ran. The 51.37% on the 3.4 branch mixes patched and unpatched.[5][6]
Not on CISA KEV as of catalog 2026.10.26 / count 1758. SSVC on the NVD row is exploitation: none / automatable: yes / technicalImpact: partial.[2][3]
NVD status Deferred; 9.3 is Patchstack Secondary, not an NVD-assigned Primary.[2]
CNA vendor “WPFactory” vs wordpress.org “WBW Plugins.” Both strings are in the records we pulled. We did not resolve the corporate name.
In-the-wild: no source we pulled claimed active exploitation of 112866. We did not scan the fleet for this slug.
The 3.4.7 information-disclosure changelog line has no CVE in the NVD keyword pull we ran for this plugin this morning.

Sources

[1] https://cveawg.mitre.org/api/cve/CVE-2026-112866 - CVE-2026-112866 CNA [2] https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-112866 - NVD CVE-2026-112866 [3] https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json - CISA KEV JSON [4] https://plugins.svn.wordpress.org/woo-product-filter/tags/3.4.7/readme.txt - woo-product-filter 3.4.7 readme [5] https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request%5Bslug%5D=woo-product-filter - wordpress.org plugin API [6] https://api.wordpress.org/stats/plugin/1.0/?slug=woo-product-filter - wordpress.org version buckets [7] https://patchstack.com/database/wordpress/plugin/woo-product-filter/vulnerability/wordpress-product-filter-by-wbw-plugin-3-4-6-sql-injection-vulnerability?_s_id=cve - Patchstack vdb-entry (CNA reference; CloudFront 403 from this box)