CVE-2024-53769: Custom Post Type to Map Store CSRF Flaw

CVE-2024-53769 Overview

CVE-2024-53769 is a Cross-Site Request Forgery (CSRF) vulnerability in the lriaudel Custom Post Type to Map Store WordPress plugin. The flaw affects all plugin versions up to and including 1.1.0. An attacker can chain the CSRF weakness to inject stored Cross-Site Scripting (XSS) payloads into the WordPress site. Successful exploitation requires an authenticated user to visit an attacker-controlled page. The stored payload then executes in the browser of any user viewing the affected content, enabling session theft, administrative action abuse, or further site compromise. The vulnerability is tracked under CWE-352: Cross-Site Request Forgery.

Critical Impact
An attacker can trick an authenticated administrator into submitting a forged request that injects persistent JavaScript into the WordPress site, leading to stored XSS execution against site visitors and administrators.

Affected Products

lriaudel Custom Post Type to Map Store plugin for WordPress
All versions from n/a through 1.1.0
WordPress sites with the cpt-to-map-store plugin installed and active

Discovery Timeline

2024-12-02 - CVE-2024-53769 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-53769

Vulnerability Analysis

The vulnerability combines two weaknesses in the Custom Post Type to Map Store plugin. The plugin exposes state-changing actions without validating anti-CSRF nonces, and it fails to sanitize user-supplied input before storing and rendering it in the WordPress database. An attacker crafts a malicious webpage containing a forged form or JavaScript request targeting the plugin's administrative endpoints. When an authenticated administrator visits this page, the browser silently submits the request using the administrator's session cookies. The forged request writes attacker-controlled JavaScript into a plugin option or post meta field. That payload later executes when any user renders the affected admin screen or public page, resulting in stored XSS with the impacted user's privileges.

Root Cause

The root cause is missing CSRF protection on plugin request handlers, compounded by inadequate output encoding. WordPress provides the wp_nonce_field() and check_admin_referer() primitives to prevent CSRF, but the affected code paths in versions up to 1.1.0 do not enforce these checks. Input intended for map store configuration is stored without sanitization by sanitize_text_field() or escaping via esc_html() on output.

Attack Vector

Exploitation requires user interaction from an authenticated site administrator or editor. The attacker hosts a page containing a hidden form or fetch() call that posts crafted parameters to the vulnerable plugin endpoint. Social engineering, such as a phishing email linking to the malicious page, delivers the payload. Because the request originates from the victim's authenticated browser, WordPress accepts it as legitimate. The injected script persists in the database and executes on subsequent page views.

No verified public proof-of-concept code is available. Refer to the Patchstack Vulnerability Report for additional technical context.

Detection Methods for CVE-2024-53769

Indicators of Compromise

Unexpected <script> tags or JavaScript event handlers stored in wp_options, wp_postmeta, or custom post type content associated with the cpt-to-map-store plugin.
WordPress access logs showing POST requests to plugin endpoints originating from external Referer headers rather than the site's own admin pages.
New or modified administrator accounts, plugin installations, or theme edits following administrator visits to untrusted links.

Detection Strategies

Audit the WordPress database for stored HTML or JavaScript in plugin-controlled fields using queries against wp_options and post meta tables.
Inspect web server access logs for POST requests to /wp-admin/admin.php or /wp-admin/admin-post.php targeting cpt-to-map-store actions without a matching prior GET from the same session.
Monitor outbound network traffic from browsers loading admin pages for connections to unfamiliar domains, which indicates exfiltration by injected scripts.

Monitoring Recommendations

Enable a web application firewall (WAF) with rules that block requests missing valid WordPress nonces on plugin admin endpoints.
Deploy Content Security Policy (CSP) headers restricting inline script execution and external script sources to detect and block injected payloads.
Alert on modifications to plugin configuration rows in the database outside of expected administrative change windows.

How to Mitigate CVE-2024-53769

Immediate Actions Required

Deactivate the Custom Post Type to Map Store plugin on any WordPress site running version 1.1.0 or earlier until a patched release is verified.
Review all plugin-managed content, options, and post meta for injected script content and remove any unauthorized entries.
Force a password reset for all administrator and editor accounts, and invalidate active sessions using wp_destroy_current_session() or equivalent.

Patch Information

At the time of publication, no fixed version is listed in the NVD entry for CVE-2024-53769. The advisory covers versions up to and including 1.1.0. Monitor the Patchstack Vulnerability Report and the plugin's official WordPress.org page for release updates addressing the CSRF and stored XSS conditions.

Workarounds

Restrict administrative access to WordPress by IP allowlisting /wp-admin/ at the web server or WAF layer to reduce the attack surface for CSRF delivery.
Require administrators to use dedicated browser profiles or sessions for WordPress management, isolating admin cookies from general web browsing.
Apply a virtual patch through a WAF that enforces Referer header validation and blocks requests targeting cpt-to-map-store endpoints without a same-origin referer.

bash

# Example: nginx location block to enforce same-origin Referer on plugin admin requests
location ~ ^/wp-admin/admin(-post|-ajax)?\.php$ {
    if ($http_referer !~* "^https?://your-site\.example/") {
        return 403;
    }
    include fastcgi_params;
    fastcgi_pass unix:/var/run/php-fpm.sock;
}