CVE-2026-64627 in parse-server
Summary
by MITRE • 07/21/2026
Parse Server versions >= 9.0.0 before 9.10.0-alpha.4 and versions before 8.6.85 contain a schema disclosure vulnerability. When the GraphQL API is mounted with public introspection disabled (graphQLPublicIntrospection: false, the default), schema-derived 'Did you mean ...?' suggestions were still returned in GraphQL error messages produced during variable coercion, which were not covered by the introspection-hardening control (that only handled validation errors). An unauthenticated caller possessing only the public application id can iteratively recover hidden schema identifiers — including registered Cloud Code function names and Parse class and field names — by submitting queries or mutations whose variables contain near-miss enum values or input-object field names. This is a follow-up bypass of GHSA-8cph-rgr4-g5vj. The issue is fixed in 9.10.0-alpha.4 and 8.6.85.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/21/2026
This vulnerability represents a sophisticated schema disclosure flaw that undermines the security controls designed to protect Parse Server applications from unauthorized schema enumeration. The issue affects versions 9.0.0 through 9.10.0-alpha.3 and all versions prior to 8.6.85, creating a significant risk for organizations relying on Parse Server for their backend services. The vulnerability specifically targets the GraphQL API implementation where public introspection has been disabled as a security measure, yet the system still leaks sensitive schema information through error messages that contain 'Did you mean ...?' suggestions.
The technical flaw exploits a gap in the GraphQL error handling mechanism where variable coercion errors generate helpful error messages containing schema-derived suggestions. While the graphQLPublicIntrospection setting correctly prevents direct introspection queries from revealing the schema structure, it fails to account for error messages generated during variable processing. This creates an indirect information disclosure channel that allows attackers to iteratively reconstruct the application schema through carefully crafted malformed requests. The vulnerability is particularly dangerous because it requires only the public application ID, making it accessible to anyone with basic knowledge of the target system.
The operational impact of this vulnerability extends beyond simple information disclosure, as it enables attackers to perform reconnaissance activities that could lead to more sophisticated attacks. By iteratively submitting queries with near-miss values, threat actors can discover registered Cloud Code function names, Parse class structures, and field definitions without requiring authentication credentials. This information gathering capability directly supports other attack vectors including potential injection attacks against discovered endpoints, enumeration of sensitive data fields, and identification of potential targets for further exploitation. The vulnerability creates a pathway for attackers to understand the application's internal structure and identify weak points in the system architecture.
Organizations should immediately update their Parse Server installations to versions 9.10.0-alpha.4 or 8.6.85 to address this vulnerability, as the issue represents a persistent security gap that could be exploited by adversaries with minimal technical expertise. The fix implemented in these versions ensures that error messages generated during variable coercion no longer contain schema-derived suggestions, effectively closing the bypass channel that existed in previous releases. This remediation aligns with security best practices outlined in CWE-209 and follows the principles established in the ATT&CK framework for preventing information disclosure through application interfaces. The vulnerability demonstrates the importance of comprehensive security testing that considers indirect information leakage channels beyond traditional direct access controls, emphasizing the need for thorough validation of all error handling mechanisms in API implementations.