CVE-2026-109382 in WSP MCP AI Agents Connector Plugin
Summary
by MITRE • 10/16/2026
The WSP MCP AI Agents Connector plugin for WordPress is vulnerable to Sensitive Information Disclosure in versions up to, and including, 2.9.5. This is due to the wsp_get_posts MCP tool being registered with an empty capability requirement while the MCP endpoint's authenticate() method accepts any logged-in user, and the wsp_execute_get_posts() callback honouring a caller-supplied status=all argument that expands into a WP_Query over 'publish', 'draft', 'pending' and 'future' posts with no author or ownership filter. This makes it possible for authenticated attackers, with Subscriber-level access and above, to read the titles, URLs, authors, categories, tags and 40-word excerpts of every unpublished (draft/pending/scheduled) post on the site.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/16/2026
The WSP MCP AI Agents Connector plugin for WordPress contains a critical information disclosure vulnerability in versions up to and including 2.9.5 that allows authenticated attackers with low-privilege accounts, such as Subscribers, to access sensitive unpublished content. This flaw stems from an improper implementation of capability checks within the Model Context Protocol (MCP) integration layer. Specifically, the wsp_get_posts MCP tool is registered without enforcing any specific WordPress capabilities or role restrictions during its definition phase. While the endpoint's authenticate() method correctly verifies that a user is logged in, it fails to validate whether the authenticated user possesses sufficient privileges to execute administrative or editorial functions. This creates a significant gap between authentication and authorization, allowing users with minimal access levels to invoke tools intended for higher-privileged roles.
The technical mechanism of this vulnerability relies on how the wsp_execute_get_posts() callback processes incoming requests. The function accepts a caller-supplied status parameter that defaults to all if not explicitly restricted by stricter logic elsewhere in the codebase. When set to all, this argument expands into a WP_Query object that retrieves posts across multiple statuses: publish, draft, pending, and future. Crucially, this query lacks any author or ownership filters, meaning it does not restrict results to content created by the requesting user. As a result, an attacker can retrieve metadata including titles, URLs, authors, categories, tags, and forty-word excerpts for every unpublished post on the site. This exposure is particularly severe because draft and pending posts often contain sensitive business logic, unreleased marketing strategies, or confidential internal communications that are not intended for public consumption even by other logged-in users.
From a security standards perspective, this vulnerability aligns with CWE-200: Information Exposure, where an attacker gains access to information that is not supposed to be available to them. It also reflects aspects of CWE-862: Missing Authorization Check, as the application fails to enforce proper access control policies for specific resources. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1005: Data from Local System and potentially T1530: Data from Cloud Storage if the content is synced externally, representing a classic case of broken object level authorization where the application trusts user-supplied input regarding data scope without verifying ownership or permission. The impact extends beyond simple privacy violations; exposure of unpublished posts can reveal intellectual property, regulatory compliance details, and internal operational workflows that could aid further attacks such as social engineering or targeted exploitation of known but unreleased features.
Mitigation strategies must address both the immediate code flaw and broader architectural principles for handling sensitive data in WordPress plugins. The primary fix involves implementing strict capability checks within the wsp_execute_get_posts() callback before executing any database queries. Developers should verify that the current user has at least editor-level privileges or a custom capability explicitly granted to access unpublished content, using functions like current_user_can(). Additionally, the WP_Query arguments must include an author parameter set to the ID of the currently authenticated user when retrieving drafts and pending posts, ensuring users only see their own work unless they hold elevated permissions. It is also recommended to implement role-based access control at the MCP tool registration level rather than relying solely on authentication checks in the endpoint handler. Organizations should immediately update the plugin to a patched version that enforces these restrictions and conduct an audit of other MCP tools to ensure similar authorization gaps do not exist elsewhere in the integration layer.