CVE-2026-119700 in WPGraphQL Plugin
Summary
by MITRE • 10/30/2026
WPGraphQL before 2.24.2 contains an information disclosure vulnerability that allows unauthenticated attackers to determine object existence through distinct error responses. Attackers can iterate IDs against deleteMediaItem, updateMediaItem, deleteComment and updateComment mutations to discover hidden draft, private, trashed posts, custom post types, and unapproved comments.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in WPGraphQL versions prior to 2.24.2 represents a significant information disclosure flaw rooted in the framework's error handling mechanisms for GraphQL mutations. This issue specifically affects endpoints such as deleteMediaItem, updateMediaItem, deleteComment, and updateComment. The core technical deficiency lies in how the application distinguishes between different failure states when processing these requests. Instead of returning uniform or generic error messages that obscure the underlying state of the requested resource, the system generates distinct error responses based on whether the target object exists within the database but is inaccessible due to permissions, versus cases where the object does not exist at all. This differential behavior creates a side-channel through which an unauthenticated attacker can perform enumeration attacks against WordPress content entities.
From a technical perspective, this vulnerability exploits the lack of consistent error abstraction in the GraphQL API layer. When an attacker submits a mutation targeting a specific identifier for media items or comments, the server's response payload varies depending on the existence and visibility status of that resource. For instance, attempting to delete a non-existent item might yield one type of error code or message, while attempting to modify an existing but private draft post may trigger a different permission-related error. By systematically iterating through sequential IDs against these mutation endpoints, attackers can map out the internal structure of the WordPress installation. This process allows them to identify hidden drafts, private posts, trashed items, custom post types that are not publicly accessible, and unapproved comments without possessing valid administrative credentials or even standard user authentication tokens.
The operational impact of this vulnerability is substantial as it facilitates reconnaissance activities that can lead to further exploitation. By discovering the existence of draft content, attackers may uncover sensitive information intended only for internal review or future publication. The identification of private posts and trashed items expands the attack surface by revealing data that administrators believed was removed or restricted from public view. Furthermore, detecting unapproved comments can provide insights into user interactions and potential social engineering targets within the community associated with the WordPress site. This level of visibility effectively negates the security controls provided by WordPress's default privacy settings for non-public content types, allowing external actors to build a detailed profile of the website's internal data structure and potentially identify high-value targets for subsequent attacks such as SQL injection or cross-site scripting if other vulnerabilities are present in those specific objects.
This vulnerability aligns with CWE-209, which describes an information exposure through an error message that reveals implementation details, although it is more accurately characterized by CWE-203, a discretionary information disclosure where the application behaves differently based on whether a resource exists or not. In terms of offensive security frameworks, this behavior maps directly to ATT&CK technique T1592.004, specifically Gather Victim Host Information: Content Discovery via API enumeration. The ability to infer object existence through response analysis is a classic pattern in web application reconnaissance that attackers leverage to map out an organization's digital footprint before launching more destructive exploits.
Mitigation for this vulnerability requires upgrading WPGraphQL to version 2.24.2 or later, where the developers have addressed these inconsistent error handling practices. In addition to applying the patch, administrators should ensure that their GraphQL endpoints are properly secured behind authentication mechanisms if they expose sensitive mutations in production environments. Implementing rate limiting on API endpoints can also help mitigate the efficiency of iterative enumeration attacks by slowing down the speed at which an attacker can probe for object existence. Regular security audits and penetration testing focused on error handling consistency across all API endpoints should be conducted to prevent similar information leakage vectors from being introduced or overlooked in future updates.