[CVE-2025-64502] Parse Server Leaks MongoDB Query Plans to Anyone Without a Master Key

TL;DR
An access-control gap lets unauthenticated users attach explain to any Parse Server query. The server dutifully asks MongoDB for a query plan and sends the full result back to the caller. Attackers can walk through every collection, learn which fields are indexed and measure how long queries take. The bug is fixed in 8.5.0-alpha.5, and a one-line configuration flag can disable public explain queries on older installations.

1. Summary

Any client that can reach your Parse endpoint can add {"explain":true} to a query and receive low-level MongoDB planning data. Knowledge of indexes, collection cardinality and query timing reduces the guesswork required for injection attacks, privilege escalation and targeted denial-of-service.

2. Context – Why query plans are a security problem

Developers often enable Parse Server because it lets them stand up a backend by flipping a switch on services like Back4App, Render or a self-hosted container. Access control is intended to be simple: everyday requests must pass an app ID, privileged requests must also pass a master key. MongoDB explain output was always considered privileged because it can reveal the entire schema.

Yet mobile SDKs from Parse, Flutter and React Native expose the explain flag in their public API. The assumption was that the server would block use without a master key. Because that check was missing, anyone with the app’s public credentials could interrogate the database structure. SaaS deployments are especially at risk because they often expose the Parse API straight to the internet.

3. Technical Details – The missing gate in RestQuery

The flaw lives in src/RestQuery.js. When a request arrives with an explain field, the code calls restFind(req, true) where the second argument instructs the database adapter to run an explain() rather than a normal find(). No path in that call chain validates the presence of X-Parse-Master-Key.

The patch in commit 4456b02280c2d8dd58b7250e9e67f1a8647b3452 adds a single conditional:

if (req.auth.isMaster || database.adapter.options.allowPublicExplain) {
  // proceed with explain
} else {
  throw new Parse.Error(Parse.Error.OPERATION_FORBIDDEN,
    'Explain is not allowed without master key');
}

A new server option named allowPublicExplain defaults to true for backward compatibility, but from 8.5.0-alpha.5 onward administrators can set it to false to restore the intended privilege boundary.

Reproducing the issue

A single cURL call is enough when pointed at any vulnerable instance:

curl -X POST https://example.com/parse/classes/_User \
  -H "X-Parse-Application-Id: myAppId" \
  -H "Content-Type: application/json" \
  -d '{"explain":true,"where":{"username":{"$ne":""}}}'

The response contains an executionStats object with index scans, stage counts and timing information.

4. Impact – From schema reconnaissance to faster exploitation

Having the schema in hand reduces attack effort in several ways. An attacker can:

• Identify which fields control access (for example, isAdmin flags) and how they are indexed, guiding injection payloads.
• Measure query latency and craft requests that lock poorly indexed paths, degrading performance for legitimate users.
• Understand naming conventions and relationships, speeding up brute-force searches for sensitive data such as password reset tokens.

Because no authentication is required, the vulnerability also lowers the bar for automated reconnaissance by botnets that sweep exposed Parse endpoints.

5. Remediation – Close the door

Upgrade to Parse Server 8.5.0-alpha.5 or any later release. If you cannot upgrade immediately:

1. Set allowPublicExplain:false in the database adapter section of parseServerOptions.
2. Add middleware that checks for explain in the request body and rejects the call unless req.info.masterKey is present.
3. Monitor logs for sudden spikes in explain usage. Legitimate traffic rarely needs query plans.

These mitigations are low effort and avoid breaking changes.

6. Timeline

7. References

• GitHub advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7cx5-254x-cgrq
• Patch commit: https://github.com/parse-community/parse-server/commit/4456b02280c2d8dd58b7250e9e67f1a8647b3452
• Pull request discussion: https://github.com/parse-community/parse-server/pull/9890

About Volerion

Volerion delivers AI-driven enrichment minutes after a CVE goes live. A single call to our REST API returns CVSS 4.0 vectors, exploitability metrics and affected products complete with remediation. Additionally, we offer different scoring profiles, complete with insight into the eight comprehensive categories that make up the final score. Our API is also available in the traditional NVD API 2.0 format, so integration is as simple as swapping hosts. Spend less time parsing CVEs and more time closing them.

How the Volerion Risk Score Fits With CVSS, EPSS and KEV

At the time of writing:

• This CVE is scored at 7.5 using CVSS 3.1, reflecting a high confidentiality impact with no integrity or availability loss.
• EPSS assigns a score of 0, which means the model currently sees little evidence that large-scale exploitation is imminent.
• CISA has not listed the vulnerability in KEV, so federal agencies are not yet under a binding directive to patch.

The Volerion Risk Score combines these signals with additional factors such as exploit maturity, product popularity and remediation difficulty. For CVE-2025-64502 that calculation lands at 7.4, flagging the issue as a high-priority information disclosure even though EPSS predicts low near-term exploitation.