CVE-2026-13736 exposes a multi-context access control failure in a WordPress plugin that synchronizes member data with WildApricot, an external membership management platform. The plugin includes field-level privacy controls that hide member data from non-logged-in visitors on the frontend — but these controls do not apply to REST API endpoints, allowing unauthenticated attackers to retrieve names, email addresses, and phone numbers of members who expected their information to be private.
The critical insight here is that the developers built privacy controls at all. This wasn't a case of ignoring data protection entirely; they implemented field-level gating for the WordPress frontend. The vulnerability exists because their implementation only modeled the traditional PHP request lifecycle — where user state is tied to session cookies — and didn't account for REST API authentication, which operates through a separate pathway (nonces, application passwords) that may not pass through the same membership status checks. They tested their privacy feature by visiting the site logged out and saw fields hidden; they never tested querying the API as an anonymous requester.
This pattern — privacy enforced on the frontend but bypassed via API — has been documented in the WordPress ecosystem since at least 2017. What elevates the stakes for this specific CVE is the integration surface. This plugin serves as a data pipeline between WordPress and WildApricot. The exposed data isn't just a profile field in a standalone site — it's member information from a system where people pay for access to membership directories. The exposure potentially affects cross-platform trust assumptions that members made when providing their data to the external platform.
The fix isn't simply adding a capability check to this specific endpoint. The systematic issue is that privacy policies defined at the application layer aren't architecturally connected to the endpoint layer, so each new REST route can bypass existing controls without any friction. The long-term solution requires making privacy a property of the data layer that any endpoint must inherit — not a property of specific route handlers that can be selectively forgotten.
For immediate action: audit any WordPress plugin that exposes REST endpoints and also claims to restrict data access based on user status. Test those endpoints as an anonymous requester (no authentication headers) rather than assuming frontend access controls apply. If the plugin bridges to external services, the sensitivity bar should be higher — integration plugins create data pipelines where a single endpoint bypass can expose information across platforms.