CVE-2026-15300 in GEO my WP Plugin
Summary
by MITRE • 07/10/2026
The GEO my WP plugin for WordPress was vulnerable to SQL Injection via the 'distance', 'lat', and 'lng' parameters in versions up to, and including, 4.5.4. The values were read from $_SERVER['QUERY_STRING'] via parse_str() (bypassing wp_magic_quotes, which does not cover $_SERVER), then passed through bare esc_sql() before being interpolated into unquoted numeric positions in the proximity-search query (HAVING/SELECT clause distance math, BETWEEN bounding-box pre-filter) built by gmw_locations_query() in plugins/posts-locator/includes/class-gmw-wp-query.php. Because esc_sql() only escapes string delimiters and these positions are numeric, payloads such as `1 OR SLEEP(3)` survived sanitization. Fixed in 4.5.5 by adding an upstream is_numeric() guard that short-circuits the WHERE clause to `AND 1 = 0` when either coordinate is non-numeric, and by replacing the three esc_sql() calls with (float) casts.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/10/2026
The GEO my WP plugin for WordPress presents a critical sql injection vulnerability affecting versions up to and including 454 where attackers can manipulate proximity search functionality through specifically crafted distance parameters. This vulnerability resides in the plugin's handling of geographic location data within the posts locator component that processes user queries for finding nearby content. The flaw manifests when the plugin reads coordinate values from $_SERVER['QUERY_STRING'] using parse_str() function which bypasses WordPress's wp_magic_quotes protection mechanism since this sanitization only covers input from standard request methods but not server variables.
The technical execution pathway involves multiple stages of inadequate input validation where the plugin processes latitude and longitude parameters through a series of insufficient sanitization measures. The values obtained from the query string undergo transformation through bare esc_sql() function calls without proper type checking or conversion, despite these parameters being destined for numeric positions within sql queries. This vulnerability operates within the context of proximity search functionality that constructs complex queries using HAVING and SELECT clauses containing mathematical distance calculations along with BETWEEN bounding box pre-filters to optimize performance.
The operational impact of this vulnerability allows attackers to inject malicious sql payloads directly into numeric query positions where traditional escaping mechanisms fail because esc_sql() only handles string delimiters and does not address numeric injection vectors. Attackers can exploit this by submitting payloads such as 1 OR SLEEP(3) which successfully bypass the sanitization process since the numeric fields do not require string escaping, enabling time-based sql injection attacks that can reveal database structure information or extract sensitive data through timing variations.
This vulnerability directly maps to CWE-89 sql injection weakness category and aligns with ATT&CK technique T1071.004 application layer protocol command execution, specifically targeting web application security controls. The fix implemented in version 455 addresses this issue by introducing upstream is_numeric() validation that immediately terminates query processing when non-numeric coordinates are detected, effectively short-circuiting the sql generation process through an AND 1 = 0 clause that renders any subsequent malicious queries ineffective. Additionally, the solution replaces vulnerable esc_sql() calls with explicit (float) type casting operations that properly validate and convert input data to their intended numeric format before processing.
The remediation approach follows industry best practices for preventing sql injection by implementing proper input validation at multiple layers including early detection of invalid data types and explicit conversion to expected formats. This solution prevents the vulnerability from occurring at the point where untrusted data enters the application, rather than attempting to sanitize data after it has been processed through potentially vulnerable functions. The change effectively eliminates the vector for time-based sql injection attacks while maintaining proper functionality for legitimate geographic search queries. Security practitioners should prioritize updating affected installations immediately since this vulnerability provides attackers with direct database access capabilities that could lead to complete system compromise and data exfiltration.
The vulnerability demonstrates how seemingly minor implementation details in input processing can create significant security risks, particularly when dealing with mixed data types in web applications. The use of parse_str() on server variables combined with insufficient type checking creates a dangerous combination that bypasses standard protection mechanisms. This case study emphasizes the importance of proper input validation and the necessity of implementing defense-in-depth strategies that protect against multiple attack vectors rather than relying solely on single layers of security controls.