CVE-2026-18035

If you're running User Access Manager on any WordPress installation, assume content you believe is restricted is currently accessible via the REST API. The plugin's access control was never designed to enforce restrictions at the data layer — it only hooks into WordPress's presentation pipeline (template rendering, query filters), which the REST API bypasses entirely. This isn't a regression where a previously-secure implementation got broken; it's the plugin's original security model finally becoming visible for what it always was: display-layer security theater that only works when content flows through normal WordPress page loads. The practical implication is that any endpoint exposing post content — /wp-json/wp/v2/posts, /wp-json/uam/v1/, or custom routes the plugin registers — will return restricted content to unauthenticated or unauthorized requests. You need to audit which post types and custom post types User Access Manager protects, then verify that the REST API responses for those objects actually enforce your intended restrictions. If you can't confirm the plugin's REST endpoints apply the same group-based access rules as its frontend checks, you have a data exposure vector. This pattern — REST API sidestepping presentation-layer access controls — isn't unique to this plugin. It's been a documented vulnerability class in WordPress since at least 2016-2017, appearing across dozens of plugins. The persistence reflects a cultural problem in WordPress plugin development: developers inherit access control patterns from existing plugins that were never correct for API access, treating them as best practice rather than known weaknesses. The WordPress REST API has existed since 2014; the ecosystem has had a decade to learn this lesson and hasn't. On the EPSS score: it likely undercounts this risk not because the vulnerability is rare, but because EPSS models attacker opportunity (exposed instances) rather than attacker intent. A plugin protecting sensitive content has catastrophically different risk than EPSS suggests when even one installation's restricted data becomes publicly enumerable through API enumeration.

Reviewed through automated stages and approved by a human before publication.