Description

The GeoDirectory plugin for WordPress is vulnerable to SQL Injection via the stored latitude/longitude coordinates of a listing in versions up to, and including, 2.8.186. This is due to insufficient escaping and the absence of numeric validation on coordinate values when a listing is saved, combined with the direct string interpolation of those values into a distance sub-expression in geodir_gps_query_part() that is later executed by the public wp_ajax_nopriv_geodir_widget_listings handler when a caller supplies set_post=<pending-listing-id> and sort_by=distance_asc. This makes it possible for authenticated attackers, with Subscriber-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-03T06:16:41.800Z",
  "pubdate": "2026-10-03T06:16:41.800Z",
  "executiveSummary": "The GeoDirectory plugin for WordPress is susceptible to a stored SQL injection vulnerability, tracked in versions up to and including 2.8.186.\nThe vulnerability arises from improper handling of latitude and longitude coordinate data provided during the listing creation process.\nAn attacker with at least Subscriber-level privileges can manipulate coordinate fields to inject malicious SQL commands.\nWhen a listing is subsequently processed by the geodir_gps_query_part() function, these payloads are interpolated directly into database queries.\nThe vulnerability is reachable via the wp_ajax_nopriv_geodir_widget_listings AJAX handler, allowing remote exploitation when specific parameters like set_post and sort_by are supplied.\nSuccessful exploitation facilitates unauthorized database interaction, potentially enabling the extraction of sensitive information, metadata, or other restricted content.\nThe risk is significant due to the accessibility of the affected AJAX endpoint and the ability to bypass standard input validation, highlighting the necessity for robust server-side sanitization.",
  "technicalDetails": "The root cause of this vulnerability is the lack of strict numeric validation and insufficient input sanitization of latitude and longitude metadata stored within listing objects. While these coordinates are expected to be decimal values, the plugin fails to enforce type safety or escape the input before persistence.\nThe vulnerable code path initiates in the listing submission process, where user-supplied coordinate values are saved to the database. These values are later retrieved and passed to the geodir_gps_query_part() function, which constructs a complex distance-based sub-expression for SQL queries.\nThe flaw manifests specifically when the wp_ajax_nopriv_geodir_widget_listings handler is invoked. By triggering this action with the sort_by=distance_asc parameter alongside a valid set_post ID, the application executes the contaminated distance sub-expression.\nBecause the latitude and longitude variables are interpolated as direct strings into the SQL statement, an attacker can break out of the intended numeric context. By crafting a coordinate input that includes SQL syntax (e.g., utilizing UNION SELECT or stacked query techniques), an authenticated attacker can append arbitrary SQL commands to the core query.\nThe attack flow is as follows: 1) An attacker authenticates as a Subscriber and creates or updates a listing, injecting a malicious SQL payload into the latitude or longitude fields. 2) The plugin saves the tainted input directly into the database. 3) The attacker triggers the wp_ajax_nopriv_geodir_widget_listings AJAX action with the 'sort_by=distance_asc' parameter. 4) The 'geodir_gps_query_part()' function retrieves the malicious payload and integrates it into the database query execution. 5) The database executes the injected commands, returning sensitive information via the AJAX response or allowing for blind data exfiltration.\nThe impact includes full database access within the scope of the web application's database user, potentially resulting in the compromise of user credentials, sensitive configuration settings, or private site data. Given that the AJAX handler is publicly accessible, the vulnerability allows for remote exploitation once the malicious payload has been stored."
}