GHSA-CMJ3-WX7H-FFVG

Vulnerability from github – Published: 2026-03-11 00:16 – Updated: 2026-03-16 20:42
VLAI?
Summary
Parse Server affected by denial-of-service via unbounded query complexity in REST and GraphQL API
Details

Impact

An unauthenticated attacker can exhaust Parse Server resources (CPU, memory, database connections) through crafted queries that exploit the lack of complexity limits in the REST and GraphQL APIs.

All Parse Server deployments using the REST or GraphQL API are affected.

Patches

The vulnerability is fixed by introducing configurable request complexity limits via the requestComplexity server option with the following keys:

  • subqueryDepth: Maximum nesting depth for $inQuery, $notInQuery, $select, $dontSelect
  • includeDepth: Maximum depth of dot-separated include paths
  • includeCount: Maximum number of include fields per query
  • graphQLDepth: Maximum depth of GraphQL field selections
  • graphQLFields: Maximum number of field selections in a GraphQL query

Requests using master key or maintenance key bypass these limits. Set any property to -1 to disable that specific limit.

In versions 8.6.15 and 9.5.2-alpha.2, these limits were enabled by default. This unintentionally introduced a breaking change for some applications with legitimate complex queries. In versions 8.6.46 and 9.6.0-alpha.22, the defaults were changed to -1 (disabled) to restore backwards compatibility.

The limits remain available as configuration options. To mitigate the vulnerability, upgrade to a patched version and set each requestComplexity property to a value appropriate for your application.

Workarounds

There is no known workaround.

References

  • GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-cmj3-wx7h-ffvg
  • Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.2
  • Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.15
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.6.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.5.2-alpha.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30946"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-11T00:16:48Z",
    "nvd_published_at": "2026-03-10T21:16:47Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAn unauthenticated attacker can exhaust Parse Server resources (CPU, memory, database connections) through crafted queries that exploit the lack of complexity limits in the REST and GraphQL APIs.\n\nAll Parse Server deployments using the REST or GraphQL API are affected.\n\n### Patches\n\nThe vulnerability is fixed by introducing configurable request complexity limits via the `requestComplexity` server option with the following keys:\n\n- `subqueryDepth`: Maximum nesting depth for `$inQuery`, `$notInQuery`, `$select`, `$dontSelect`\n- `includeDepth`: Maximum depth of dot-separated `include` paths\n- `includeCount`: Maximum number of `include` fields per query\n- `graphQLDepth`: Maximum depth of GraphQL field selections\n- `graphQLFields`: Maximum number of field selections in a GraphQL query\n\nRequests using master key or maintenance key bypass these limits. Set any property to `-1` to disable that specific limit.\n\nIn versions `8.6.15` and `9.5.2-alpha.2`, these limits were enabled by default. This unintentionally introduced a breaking change for some applications with legitimate complex queries. In versions `8.6.46` and `9.6.0-alpha.22`, the defaults were changed to `-1` (disabled) to restore backwards compatibility.\n\nThe limits remain available as configuration options. To mitigate the vulnerability, upgrade to a patched version and set each `requestComplexity` property to a value appropriate for your application.\n\n### Workarounds\n\nThere is no known workaround.\n\n### References\n\n- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-cmj3-wx7h-ffvg\n- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.2\n- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.15",
  "id": "GHSA-cmj3-wx7h-ffvg",
  "modified": "2026-03-16T20:42:11Z",
  "published": "2026-03-11T00:16:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-cmj3-wx7h-ffvg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30946"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/releases/tag/8.6.15"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Parse Server affected by denial-of-service via unbounded query complexity in REST and GraphQL API"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…