CVE-2026-19798 in Wp Map Block Plugin
Summary
by MITRE • 10/16/2026
The Wp Map Block plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the set_status() and bulk() functions in the Maps_Controller REST controller in versions up to, and including, 3.0.0. The plugin's permission_callback (can_edit()) only verifies current_user_can('edit_posts') and performs no object-level ownership check or verification of publish-level capabilities, while the handlers pass the caller-controlled map ID directly to wp_update_post() (and wp_delete_post() in the bulk delete branch) to change post_status between publish and draft. This makes it possible for authenticated attackers, with Contributor-level access and above, to publish or unpublish (and bulk-delete) any wpmb_map post, including maps owned by administrators, which hides published maps from all public pages site-wide or forces draft maps to become publicly visible.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in the Wp Map Block plugin for WordPress versions up to and including 3.0.0 represents a critical failure in access control logic within its REST API implementation. Specifically, the Maps_Controller class exposes endpoints via the set_status() and bulk() functions that allow modification of map post statuses without adequate authorization checks. The core technical flaw lies in the permission_callback function named can_edit(), which relies exclusively on the WordPress capability check current_user_can('edit_posts'). This approach is fundamentally flawed because it verifies only a general user role or capability level rather than enforcing object-level ownership or verifying that the authenticated user has specific permissions for the particular map post being modified. In standard WordPress security models, while 'edit_posts' allows users to edit their own posts, it does not inherently grant permission to modify posts owned by other users unless additional checks are implemented. By omitting these necessary verifications, the plugin fails to distinguish between a user acting on their own data and an attacker attempting to manipulate resources they do not own.
From a technical perspective, the vulnerability is exploited through direct manipulation of post metadata via REST API requests. The handlers for set_status() and bulk() accept caller-controlled map IDs and pass them directly into WordPress core functions such as wp_update_post() or wp_delete_post(). When an attacker provides a valid authentication cookie or token associated with any account possessing Contributor-level access or higher, the system processes these requests without validating whether the provided ID corresponds to a post owned by that specific user. This lack of object-level authorization allows authenticated attackers to arbitrarily change the post_status field of maps they do not own. The impact is twofold: malicious actors can unpublish legitimate maps created by administrators or other users, effectively removing them from public view and disrupting site functionality, or conversely, they can force draft maps into a published state, potentially exposing sensitive or incomplete content to the general public.
The operational impact of this vulnerability extends beyond simple data modification, affecting the integrity and availability of web services built on WordPress using this plugin. Since map visibility is often critical for location-based applications, business listings, or interactive site features, unauthorized changes can lead to significant service disruption. For organizations relying on these maps for customer engagement or internal operations, an attacker with low-privileged access could cause widespread confusion by hiding essential information or publishing unvetted content. This scenario aligns closely with CWE-862, which describes Missing Authorization, and specifically relates to CWE-915 regarding Improperly Controlled Modification of Dynamically-Determined Object Attributes. Furthermore, in the context of the MITRE ATT&CK framework for enterprise security, this vulnerability facilitates lateral movement or privilege escalation within a web application environment by allowing lower-privileged users to perform actions reserved for higher-privileged roles, such as administrators. It also touches upon CWE-798 if sensitive data is exposed through unauthorized publication of draft maps containing proprietary information.
To mitigate this risk, immediate action must be taken by plugin developers and site administrators. Developers should update the permission_callback in the Maps_Controller to include rigorous object-level ownership checks. This involves verifying that the current user ID matches the post author ID for the specific map being modified, or ensuring the user possesses explicit capabilities like 'edit_others_posts' if cross-user modification is intended but restricted appropriately. Additionally, implementing nonce verification and rate limiting on REST endpoints can provide defense-in-depth against automated exploitation attempts. Site administrators should promptly update the Wp Map Block plugin to a patched version that addresses these authorization flaws. Until an official patch is available or implemented via custom code modifications in child themes or mu-plugins, restricting access to the WordPress dashboard for all non-essential users and monitoring REST API logs for anomalous status changes can help detect and prevent exploitation of this vulnerability.