CVE-2026-105828 in Parse Server
Summary
by MITRE • 10/08/2026
Parse Server 8.2.2 before 8.6.92 and 9.0.0 before 9.10.1-alpha.12 contains an information disclosure vulnerability in which GraphQL validation error messages reveal hidden class names when public introspection is disabled. Unauthenticated attackers holding only the public Application Id can send crafted operations triggering unknown-argument or invalid enum value errors to learn pointer and relation target classes.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/08/2026
Parse Server versions 8.2.2 through 8.6.91, as well as version 9.0.0 up to 9.10.1-alpha.11, are susceptible to an information disclosure vulnerability within the GraphQL API layer. This flaw specifically affects environments where public introspection has been explicitly disabled in an attempt to restrict schema visibility and enhance security posture. Despite this configuration setting intended to hide internal data structures from unauthenticated users, the error handling mechanism for GraphQL validation failures inadvertently leaks sensitive architectural details. The core issue lies in how the server processes malformed or invalid queries when strict access controls are active, creating a side-channel through which an attacker can infer hidden class names and relationships that should remain opaque.
The technical root cause of this vulnerability is tied to the specific error messages generated during GraphQL validation phases. When an unauthenticated user submits crafted operations containing unknown arguments or references to invalid enum values, the server returns detailed validation errors rather than generic failure responses. These verbose error messages include pointers to class names that are not part of the public schema but exist within the backend data model. By analyzing these specific error outputs, particularly those related to argument parsing and enum value verification, an attacker can systematically deduce the existence and naming conventions of hidden classes. This process does not require authentication or any form of privilege escalation; possession of a valid public Application Id is sufficient to initiate the attack sequence against the GraphQL endpoint.
From an operational perspective, this vulnerability allows for significant reconnaissance by unauthenticated adversaries. The ability to enumerate internal class names provides attackers with critical insights into the application's data model and relationship structures. This information can be leveraged in subsequent attacks to craft more precise queries targeting specific endpoints or to identify potential weaknesses in access control logic associated with those hidden classes. While this vulnerability alone does not permit direct data exfiltration, it significantly lowers the barrier for further exploitation by revealing the underlying architecture of the Parse Server instance. The disclosure of pointer and relation target classes effectively undermines the security boundary established by disabling public introspection, rendering that mitigation ineffective against determined attackers who can analyze error responses.
This flaw aligns with CWE-209, which describes the generation of an error message that includes sensitive information useful to an attacker, such as stack traces or internal paths. It also relates to CWE-749, where exposed security constraints are bypassed due to improper implementation of access controls. In terms of offensive tactics, this behavior corresponds to ATT&CK technique T1087, specifically the enumeration of account names and local accounts via API queries, as well as T1602 for data obfuscation evasion through error message analysis. The vulnerability highlights a common pitfall in web application development where developers assume that disabling introspection is sufficient without ensuring that all code paths, including error handling routines, respect those restrictions.
To mitigate this risk, organizations running affected versions of Parse Server should immediately upgrade to version 8.6.92 or later for the 8.x branch, and version 9.10.1-alpha.12 or later for the 9.x development line. These updates address the underlying issue by ensuring that validation error messages do not expose internal class names when public introspection is disabled. In addition to upgrading, administrators should review their GraphQL configuration to ensure that verbose error reporting is strictly limited in production environments. Implementing generic error responses for unauthenticated users and monitoring logs for repeated attempts to trigger these specific validation errors can provide additional layers of defense against exploitation. Regular security audits focusing on API response sanitization are recommended to prevent similar information leakage vectors in other parts of the application stack.