WP Multi Store Locator Pro CVE-2026-15275

No special conditions - remote unauthenticated exploitation against default configurations of WP Multi Store Locator Pro (≤4.5.1). The vulnerable AJAX handler is registered on wp_ajax_nopriv_make_search_request with no nonce or capability check, so it is reachable by any anonymous visitor via admin-ajax.php; the only prerequisite is that the plugin is installed and active. The single limiting factor is the numeric injection point ('store_locatore_search_radius'), but rather than limiting exploitation it aids it, since the unquoted numeric context defeats WordPress's wp_magic_quotes()/addslashes protection. No user interaction, authentication, or non-default setting is required.

This is a genuinely high-priority issue by all technical signals that are present, though exploitation intelligence is thin. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, base 7.5) is fully consistent with the description: a network-reachable, low-complexity, unauthenticated flaw. The description independently corroborates the PR:N claim by naming the exact mechanism - the AJAX action is registered on 'wp_ajax_nopriv_make_search_request' with no nonce or capability check - so the unauthenticated designation is confirmed rather than inferred. Confidentiality impact is C:H (database extraction) while I:N/A:N reflects a read-oriented UNION/blind SQLi rather than data modification or DoS, which is a reasonable scoping. A notable exploitability amplifier called out in the description is that the injection occurs in a numeric, unquoted SQL context, so WordPress's wp_magic_quotes()/addslashes protection cannot neutralize the payload - this removes a defense that often blunts otherwise-similar bugs. Against these strong signals, there is NO EPSS score, NO CISA KEV listing, and NO public POC in the provided data, so there is no evidence of active or automated exploitation at time of analysis; treat exploitation status as 'no public exploit identified.' SSVC framing: exploitation=none observed, but automatable=likely-yes (unauthenticated, no UI, single parameter) and technical impact=partial-to-total for confidentiality - so the absence of a KEV entry reflects lack of observed campaigns, not low weaponizability. No key CVSS/description conflicts exist; the main gap is the missing patched version (see confidence notes).

An unauthenticated attacker sends a crafted POST/GET request to admin-ajax.php with action=make_search_request and a malicious 'store_locatore_search_radius' value in a numeric SQL context, appending a UNION or stacked query. Because the parameter is unquoted, addslashes-based escaping does not apply, and the query returns or leaks WordPress user records, password hashes, or other database contents. No public exploit code is identified in the provided data, but the single-parameter, unauthenticated nature makes weaponization straightforward.