CVE-2026-30835
Information Disclosure via Malformed $regex in Parse Server API
Publication date: 2026-03-06
Last updated on: 2026-03-11
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| parseplatform | parse-server | From 9.0.0 (inc) to 9.5.0 (exc) |
| parseplatform | parse-server | 9.5.0 |
| parseplatform | parse-server | 9.5.0 |
| parseplatform | parse-server | 9.5.0 |
| parseplatform | parse-server | 9.5.0 |
| parseplatform | parse-server | 9.5.0 |
| parseplatform | parse-server | to 8.6.7 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-209 | The product generates an error message that includes sensitive information about its environment, users, or associated data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-30835 is a vulnerability in the parse-server npm package where malformed $regex query parameters (for example, an incomplete regex like [abc) cause the database to return detailed structured error objects.'}, {'type': 'paragraph', 'content': 'These error objects are passed unsanitized through the API response, which leaks sensitive database internals such as error messages, error codes, code names, cluster timestamps, and topology details.'}, {'type': 'paragraph', 'content': "The vulnerability can be exploited by any client capable of sending query requests, depending on the deployment's permission configuration, without requiring privileges or user interaction."}, {'type': 'paragraph', 'content': 'The root cause is the generation and exposure of detailed error messages containing sensitive information (CWE-209).'}, {'type': 'paragraph', 'content': 'This issue has been fixed in parse-server versions 8.6.7 and 9.5.0-alpha.6 by sanitizing error responses so that clients only receive a generic error message, while detailed errors are logged server-side.'}] [1]
How can this vulnerability impact me? :
This vulnerability can lead to information disclosure by leaking sensitive internal database details through API error responses.
An attacker who can send query requests to the parse-server can exploit this to gain insights into the database structure, error codes, cluster timestamps, and topology details.
Such information leakage can aid attackers in crafting more targeted attacks or understanding the backend infrastructure, potentially increasing the risk of further exploitation.
No privileges or user interaction are required to exploit this vulnerability, making it easier for remote attackers to gather sensitive information.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by sending malformed $regex query parameters (e.g., [abc) to the Parse Server API and observing the responses.'}, {'type': 'paragraph', 'content': 'If the server returns detailed structured error objects containing database internals such as error messages, error codes, code names, cluster timestamps, or topology details, it indicates the presence of the vulnerability.'}, {'type': 'paragraph', 'content': 'A possible command to test this could be a curl request like:'}, {'type': 'list_item', 'content': 'curl -X GET \'https://your-parse-server.com/classes/YourClass?where={"field":{"$regex":"[abc"}}\' -H \'X-Parse-Application-Id: YOUR_APP_ID\''}, {'type': 'paragraph', 'content': 'If the response contains detailed error information rather than a generic error message, the server is vulnerable.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
The only effective mitigation is to upgrade the parse-server to a patched version.
- Upgrade to parse-server version 8.6.7 or later, or 9.5.0-alpha.6 or later, where the vulnerability has been fixed.
No workaround exists because the error leakage occurs at the query execution layer and cannot be mitigated through server configuration or client-side changes.