CVE-2026-8839: MapPress Maps WordPress Plugin Authorization Bypass Vulnerability

Technical summary

The vulnerability stems from two distinct authorization failures in the MapPress REST API implementation. First, the GET endpoint `/wp-json/mapp/v1/maps/{mapid}` uses `'permission_callback' => '__return_true'`, permitting unauthenticated access to any map. Second, write operations (POST update, DELETE, PATCH mutate, POST clone, POST empty_trash) only validate the generic `edit_posts` capability without confirming ownership of the specific map resource. This pattern repeats at the model layer: the underlying `Mappress_Map` methods (`get()`, `save()`, `delete()`, `mutate()`, `empty_trash()`) accept caller-supplied map IDs without performing any ownership checks, leaving the authorization decision entirely to the REST API layer, which itself is incomplete.

Business impact

Organizations using MapPress to manage location-based content—event venues, branch locations, property listings, or restricted point-of-interest databases—face exposure of geospatial data and associated metadata that may be sensitive or competitive. Authenticated attackers with contributor access can sabotage published maps by deletion or modification, disrupting site functionality and potentially damaging user trust. The ease of exploitation via simple ID enumeration means the attack surface is broad and requires no special tools or insider knowledge.

Affected systems

The MapPress Maps for WordPress plugin in all versions up to and including 2.96.6 is affected. Any WordPress installation using this plugin version range is vulnerable regardless of plugin configuration or visibility settings. The vulnerability requires only that the WordPress REST API is enabled (default in recent WordPress versions) and that the MapPress plugin is active.

Exploitability

Exploitation requires no authentication to read map data and trivial effort to enumerate map IDs. An attacker can discover maps by incrementing the map ID parameter and harvesting sensitive location data. Modifying or deleting maps requires a WordPress account with contributor-level permissions or higher, but once obtained, those accounts can tamper with any map. The lack of any additional controls (CAPTCHA, rate-limiting, audit logging at the API level) means attacks are difficult to detect in real time and can operate at scale.

Remediation

Update the MapPress Maps plugin immediately to the patched version. Verify against the official plugin repository or vendor advisory for the minimum safe version number. As an interim mitigation before patching, disable REST API access via a security plugin or `.htaccess` rule targeting `wp-json/mapp/` endpoints if the plugin cannot be updated immediately. Monitor logs for unusual `wp-json/mapp/` requests, particularly enumeration patterns in the mapid parameter.

Patch guidance

Obtain the latest version from the official MapPress plugin repository on wordpress.org and apply it via the WordPress admin panel or direct file replacement. Verify that the update includes ownership verification logic in both REST API permission callbacks and the underlying model methods. Test that unauthenticated requests to `/wp-json/mapp/v1/maps/` return 403 Forbidden rather than map data. Confirm that authenticated non-owner requests to modify or delete maps return 403 Forbidden.

Detection guidance

Monitor WordPress logs and audit trails for repeated requests to `/wp-json/mapp/v1/maps/` with sequential or random mapid values from the same IP, which suggests enumeration. Look for requests originating from users with contributor access that attempt modifications to maps owned by other authors. Enable query logging on the database and watch for unexpected writes to the MapPress tables originating from non-standard request contexts. Web application firewalls can be configured to flag POST/DELETE/PATCH requests to the mapp endpoint from unusual source IPs or at unusual times.

Why prioritize this

Although the CVSS score is Medium (5.3), the vulnerability combines high exploitability (unauthenticated, no user interaction) with low friction execution and potential impact across all published maps. Sites storing sensitive location data should prioritize patching. Organizations with strict authentication policies or those running older WordPress versions with lower contributor-base activity face lower risk but should still patch promptly.

Risk score, explained

The CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N score reflects network accessibility, low attack complexity, no authentication requirement, and integrity impact (modification/deletion). Confidentiality is rated as None because the vector focuses on the integrity dimension; however, in practice, the unauthenticated read access to map data represents a meaningful confidentiality concern that should factor into organizational risk assessment independent of the numeric score.

Frequently asked questions