CVE-2026-92099 in Smart Cache Plugin
Summary
by MITRE • 09/19/2026
The WPGraphQL Smart Cache WordPress plugin before 2.3.2 does not require authorisation or validate a caller-supplied query identifier before storing a persisted query from a request, allowing unauthenticated users to publish arbitrary query documents and claim query aliases before a site's own frontend registers them.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/19/2026
The vulnerability identified in WPGraphQL Smart Cache versions prior to 2.3.2 represents a critical authentication bypass within the plugin’s persistent query management subsystem. This flaw stems from an insufficient access control mechanism that fails to verify the identity or authorization status of users attempting to store GraphQL queries for caching purposes. Specifically, when a request is made to register a persisted query with a specific alias, the application logic does not enforce any form of authentication check before accepting and storing this data in its internal registry. This design oversight allows unauthenticated actors on the internet to interact directly with the plugin’s API endpoints without needing valid credentials or session tokens, effectively treating public users as trusted administrators for cache management operations.
From a technical perspective, the core issue lies in the lack of validation regarding who is permitted to claim query aliases within the WordPress environment. In typical GraphQL implementations using WPGraphQL, persisted queries are often used to optimize performance by allowing clients to reference complex queries via simple string identifiers rather than sending full query strings with every request. The vulnerability exploits this feature by enabling an attacker to pre-register arbitrary query documents under specific aliases that a legitimate site’s frontend might subsequently attempt to use. By publishing these arbitrary query documents and claiming the corresponding aliases, the attacker creates a conflict where their malicious payload takes precedence or interferes with the expected behavior of the application when it attempts to resolve those same identifiers during normal operation.
The operational impact of this vulnerability is significant, primarily centering on potential data integrity issues and service disruption rather than direct remote code execution in isolation. An unauthenticated attacker can manipulate the caching layer by injecting malicious GraphQL queries that may attempt to exfiltrate sensitive database information, such as user credentials or private content, if those operations are permitted by the underlying WordPress permissions schema but not properly restricted at the cache registration level. Furthermore, this behavior facilitates a form of denial-of-service through resource exhaustion or logic confusion. If an attacker claims aliases that legitimate frontend components rely on, it can cause application errors, broken functionality, or unexpected responses for genuine users, thereby degrading the availability and reliability of the web service.
This vulnerability aligns with CWE-287, which describes Improper Authentication, as the system fails to correctly verify the identity of a user prior to performing an action that should be restricted. Additionally, it relates to CWE-611, Improper Restriction of XML External Entity References or similar injection flaws depending on how the query is processed later, though in this context, it is more accurately categorized under CWE-862, Missing Authorization, because the primary failure is the lack of permission checks for a specific function. In terms of attack vectors, this falls under MITRE ATT&CK technique T1190, Exploit Public-Facing Application, where adversaries leverage vulnerabilities in internet-facing software to gain an initial foothold or disrupt services.
Mitigation strategies must focus on immediate patching and architectural review. The primary remediation is to upgrade the WPGraphQL Smart Cache plugin to version 2.3.2 or later, where this authentication gap has been addressed by implementing proper access controls that restrict query registration to authenticated users with appropriate capabilities, such as administrators or editors depending on site configuration. For sites unable to patch immediately due to compatibility concerns, temporary mitigations include restricting access to the WordPress REST API and GraphQL endpoints via web application firewall rules if possible, although this is less effective for legitimate traffic. Additionally, reviewing plugin configurations to disable persistent query registration from public-facing interfaces until a permanent fix can be applied will reduce the attack surface. Regular security audits of third-party plugins are essential to ensure that caching mechanisms do not introduce unintended privilege escalation paths or data exposure risks within the WordPress ecosystem.