CVE-2026-119702 in GraphQL Plugin
Summary
by MITRE • 10/30/2026
WPGraphQL before 2.24.1 contains a missing authorization vulnerability in the createComment mutation that allows unauthenticated attackers to comment on non-public posts by bypassing post status checks. Attackers can attach comments to draft, private, trashed, or password-protected posts to leak hidden titles via moderator notifications, enumerate post IDs, and backdate comments or mark them as pingbacks.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in WPGraphQL versions prior to 2.24.1 represents a critical failure in access control mechanisms within the GraphQL API layer of WordPress-based applications. Specifically, this flaw resides in the createComment mutation, which is designed to allow users to submit comments on posts and pages. In standard WordPress operations, comment submission is strictly governed by post status checks that prevent interaction with content not intended for public consumption. However, the implementation in WPGraphQL failed to enforce these same restrictions when processing GraphQL requests, creating a significant discrepancy between REST API behavior and GraphQL API behavior regarding authorization logic. This architectural inconsistency allows unauthenticated attackers to bypass standard security boundaries without requiring valid credentials or session tokens.
From a technical perspective, the core issue is a missing authorization check within the mutation handler for comment creation. When an attacker submits a request to createComment with a target post ID corresponding to a non-public resource—such as a draft, private, trashed, or password-protected post—the server processes the request without verifying whether the requesting user has permission to interact with that specific post type and status. The GraphQL endpoint accepts the input parameters and executes the database insertion for the comment record regardless of the target post's visibility settings. This bypass effectively neutralizes one of WordPress's primary defense-in-depth layers, which relies on post-level permissions to restrict content exposure and interaction.
The operational impact of this vulnerability is multifaceted and extends beyond simple spam or defacement. Attackers can exploit this flaw to leak sensitive information contained within the metadata of hidden posts. For instance, by submitting comments to draft or private posts, attackers may trigger moderator notification emails that reveal post titles which are otherwise inaccessible through normal browsing. This constitutes an unauthorized disclosure of confidential data and aids in reconnaissance efforts. Furthermore, the ability to attach comments to trashed or password-protected posts allows for the enumeration of internal post IDs. Since WordPress often uses sequential ID generation, successfully interacting with these hidden resources confirms their existence and provides attackers with a map of the site's content structure that should remain opaque to external observers.
Additionally, this vulnerability enables temporal manipulation attacks where attackers can backdate comments or mark them as pingbacks on restricted posts. This capability distorts the audit trail and metadata associated with specific pieces of content, potentially affecting integrity checks or forensic analysis if an incident were to occur later. The ability to interact with trashed items also suggests that data retention policies may be undermined, as deleted content remains accessible for manipulation through this API endpoint. These actions collectively degrade the confidentiality, integrity, and availability aspects of the web application's security posture by exposing internal structures and allowing unauthorized state changes on protected resources.
To mitigate this vulnerability, organizations running WPGraphQL must immediately upgrade to version 2.24.1 or later, where the authorization checks for post status have been corrected in the createComment mutation logic. Until an update is applied, administrators should consider disabling GraphQL access entirely if it is not actively required by their application stack, thereby removing the attack surface from exposure. Alternatively, implementing a Web Application Firewall rule that restricts write operations to known public post IDs can provide a temporary compensating control, although this approach requires careful tuning to avoid false positives against legitimate traffic. It is also advisable to review server logs for anomalous comment submission patterns targeting non-public endpoints as part of ongoing monitoring efforts.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically the failure to enforce proper authorization checks before allowing access to a resource. In terms of offensive security frameworks, this exploitation technique maps to ATT&CK T1078, Valid Accounts or Invalid Credentials for Initial Access, although in this specific case it leverages unauthenticated access due to misconfiguration rather than stolen credentials. It also relates to ATT&CK T1530, Data from Cloud Storage Object Buckets, if the leaked titles and IDs are considered sensitive data assets stored within the application's database structure. The incident underscores the importance of ensuring parity in security controls across different API interfaces within a single software ecosystem, as discrepancies between REST and GraphQL implementations can create exploitable gaps that attackers readily identify and utilize for further intrusion activities.