WP Inventory Manager EUVD-2026-82749

Requires an authenticated WordPress account at Contributor level or above (PR:L) on a site running WP Inventory Manager <=2.5.1, plus the ability to place a [wpinventory] shortcode with a 'where' attribute into content that gets rendered. The vulnerable parse_custom_where() only performs html_entity_decode(), strips semicolons, and does field-label name replacement - so stacked queries are blocked, but UNION and subquery injection remain viable; impact is limited to data reads (SELECT), not modification. Limiting factors: no unauthenticated path, and sites that do not grant Contributor-or-above accounts to untrusted users are not exposed.

This is a moderate-priority authenticated SQL injection. The CVSS 6.5 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) is consistent with the description: network-reachable, low-complexity, but gated behind Contributor-level authentication (PR:L) and limited to confidentiality impact (C:H, I:N, A:N) because the injection sits in a raw SELECT executed via $wpdb->get_results(). No EPSS score, KEV listing, or public POC is present in the input, so exploitation status is 'no public exploit identified at time of analysis' - do not treat this as widespread active exploitation. The realistic risk driver is the low authentication bar: Contributor is a self-registerable or loosely-granted role on many multi-author WordPress sites, and the semicolon-stripping mitigation does NOT block UNION-based or subquery data extraction, so an attacker who holds any Contributor account can read arbitrary database contents (including password hashes and secret keys). Weighed against that, it is not an unauthenticated pre-auth flaw, which keeps it below the 'drop everything' tier; treat it as a prompt-patch item on sites that allow Contributor-or-above accounts.

An attacker registers or obtains a Contributor-level account on a WordPress site running WP Inventory Manager <=2.5.1, then authors a post/page containing a [wpinventory where="..."] shortcode with a crafted UNION-based payload. When the shortcode renders, parse_custom_where() passes the unsanitized string into a raw SELECT executed by $wpdb->get_results(), returning sensitive rows (e.g., user hashes) into the rendered output. No public exploit code is identified in the provided data.