BREW-MOTO-CVE-2026-75508 (GHSA-R77W-QPH3-7VF8)

Vulnerability from osv_homebrew – Published: 2026-10-23 10:07 – Updated: 2026-10-23 10:07 – Source website
VLAI
Summary
GraphQL-core: Denial of service via comment tokens bypassing the parser's max_tokens limit
Details

Summary

The parser's max_tokens limit — the documented defence against oversized GraphQL documents — did not count comment tokens. A document padded with comments could therefore pass a max_tokens check of any size while still allocating one Token object per comment, all of which stay reachable for the lifetime of the parsed document. A 38 MB comment-padded payload allocated roughly 92 MB of additional resident memory with max_tokens=5 in force.

Details

Lexer.lookahead() reads tokens one at a time and skips over comments, returning only the first non-comment token. Each skipped comment is nevertheless fully tokenized, allocated as a Token object, and linked into the persistent token list via token.next / token.prev — the chain that powers source-location reporting, and which is retained as long as the document is.

Parser.advance_lexer() incremented the token counter only for the tokens the lexer actually returned. Comments were therefore invisible to the accounting, and max_tokens bounded only the non-comment tokens.

The practical consequence is a gap between what users reasonably believe max_tokens protects and what it did protect. The limit was not broken for ordinary documents — real tokens were still capped correctly — so the shortfall was not observable without specifically testing comment padding.

As with the companion issue, the payload compresses extremely well (# c\n repeated), so body-size limits and WAF inspection applied to the compressed request do not see its true size, while the framework decompresses it in memory before the parser is reached.

Proof of concept

import gc
import resource
from graphql import parse

# 100,000 comments, a 5-token query, and max_tokens=5 — accepted.
query = "# c\n" * 100_000 + "{ a }"
parse(query, max_tokens=5)          # no error raised

# Memory amplification.
big = "# padding comment used to amplify memory per token\n" * 500_000 + "{ a }"
gc.collect()
before = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
parse(big, max_tokens=5)            # ~38 MB source
after = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
print(f"RSS delta: +{(after - before) / 1024:.0f} MB")

Measured on GraphQL-core 3.2.8 / CPython 3.12 / Linux x86_64: the 391 KB payload parsed in 127 ms, and the 38.1 MB payload produced an RSS delta of +92 MB — about 2.4× the source size, on top of the source string itself.

Impact

Denial of service through memory exhaustion. A modest number of concurrent requests can push a worker past a typical 256 MB or 512 MB container limit and trigger an OOM kill. No authentication is required, and no data is disclosed or modified.

Depth limiters and complexity analyzers do not help: they run on the AST after parsing has already succeeded, and the document contains only five real tokens.

Patches

Fixed in 3.2.12 and 3.3.0rc1.

Parser.advance_lexer now counts every token consumed, including the comment tokens the lexer skips between the previously focused token and the new one, and including the advance onto EOF so that trailing comments are covered. max_tokens therefore now bounds every Token the parser allocates.

Note the behaviour change: comments now count toward max_tokens. A comment-heavy document that was previously accepted may now be rejected. If you parse documents containing substantial comments — SDL files with documentation comments, for instance — and you set max_tokens, you may need to raise the limit. The token_count attribute of a parsed document likewise now includes comments.

Workarounds

If you cannot upgrade, apply a request body-size limit to the decompressed body before the document reaches parse().

Such a limit is worth keeping after upgrading as well: max_tokens is one guard among several and bounds the token count, not the overall cost of a request.

References

  • GraphQL specification § 2.1.4 — Comments

Credits

Reported by @BZHunt, who also reviewed the fixes before release. In memory of ZaX, who was the driving force behind this discovery.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "graphql-core",
        "resource_purl": "pkg:pypi/graphql-core@3.3.0",
        "upstream_fixed_in": "3.3.0rc1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "moto",
        "purl": "pkg:brew/moto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.6"
            },
            {
              "fixed": "5.2.3_1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/graphql-core@3.3.0",
        "name": "graphql-core",
        "resource": "graphql-core",
        "strategy": "registry",
        "subject_version": "3.3.0"
      }
    ]
  },
  "details": "### Summary\n\nThe parser\u0027s `max_tokens` limit \u2014 the documented defence against oversized GraphQL\ndocuments \u2014 did not count comment tokens. A document padded with comments could\ntherefore pass a `max_tokens` check of any size while still allocating one `Token`\nobject per comment, all of which stay reachable for the lifetime of the parsed\ndocument. A 38 MB comment-padded payload allocated roughly 92 MB of additional\nresident memory with `max_tokens=5` in force.\n\n### Details\n\n`Lexer.lookahead()` reads tokens one at a time and skips over comments, returning only\nthe first non-comment token. Each skipped comment is nevertheless fully tokenized,\nallocated as a `Token` object, and linked into the persistent token list via\n`token.next` / `token.prev` \u2014 the chain that powers source-location reporting, and\nwhich is retained as long as the document is.\n\n`Parser.advance_lexer()` incremented the token counter only for the tokens the lexer\nactually returned. Comments were therefore invisible to the accounting, and\n`max_tokens` bounded only the *non-comment* tokens.\n\nThe practical consequence is a gap between what users reasonably believe `max_tokens`\nprotects and what it did protect. The limit was not broken for ordinary documents \u2014\nreal tokens were still capped correctly \u2014 so the shortfall was not observable without\nspecifically testing comment padding.\n\nAs with the companion issue, the payload compresses extremely well (`# c\\n` repeated),\nso body-size limits and WAF inspection applied to the compressed request do not see\nits true size, while the framework decompresses it in memory before the parser is\nreached.\n\n### Proof of concept\n\n```python\nimport gc\nimport resource\nfrom graphql import parse\n\n# 100,000 comments, a 5-token query, and max_tokens=5 \u2014 accepted.\nquery = \"# c\\n\" * 100_000 + \"{ a }\"\nparse(query, max_tokens=5)          # no error raised\n\n# Memory amplification.\nbig = \"# padding comment used to amplify memory per token\\n\" * 500_000 + \"{ a }\"\ngc.collect()\nbefore = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss\nparse(big, max_tokens=5)            # ~38 MB source\nafter = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss\nprint(f\"RSS delta: +{(after - before) / 1024:.0f} MB\")\n```\n\nMeasured on GraphQL-core 3.2.8 / CPython 3.12 / Linux x86_64: the 391 KB payload\nparsed in 127 ms, and the 38.1 MB payload produced an RSS delta of **+92 MB** \u2014 about\n2.4\u00d7 the source size, on top of the source string itself.\n\n### Impact\n\nDenial of service through memory exhaustion. A modest number of concurrent requests\ncan push a worker past a typical 256 MB or 512 MB container limit and trigger an\nOOM kill. No authentication is required, and no data is disclosed or modified.\n\nDepth limiters and complexity analyzers do not help: they run on the AST after parsing\nhas already succeeded, and the document contains only five real tokens.\n\n### Patches\n\nFixed in **3.2.12** and **3.3.0rc1**.\n\n`Parser.advance_lexer` now counts every token consumed, including the comment tokens\nthe lexer skips between the previously focused token and the new one, and including\nthe advance onto EOF so that trailing comments are covered. `max_tokens` therefore now\nbounds every `Token` the parser allocates.\n\nNote the behaviour change: **comments now count toward `max_tokens`.** A\ncomment-heavy document that was previously accepted may now be rejected. If you parse\ndocuments containing substantial comments \u2014 SDL files with documentation comments, for\ninstance \u2014 and you set `max_tokens`, you may need to raise the limit. The\n`token_count` attribute of a parsed document likewise now includes comments.\n\n### Workarounds\n\nIf you cannot upgrade, apply a request body-size limit to the **decompressed** body\nbefore the document reaches `parse()`.\n\nSuch a limit is worth keeping after upgrading as well: `max_tokens` is one guard among\nseveral and bounds the token count, not the overall cost of a request.\n\n### References\n\n- GraphQL specification \u00a7 2.1.4 \u2014 Comments\n\n### Credits\n\nReported by @BZHunt, who also reviewed the fixes\nbefore release. In memory of ZaX, who was the driving force behind this discovery.",
  "id": "BREW-moto-CVE-2026-75508",
  "modified": "2026-10-23T10:07:03Z",
  "published": "2026-10-23T10:07:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/graphql-python/graphql-core/security/advisories/GHSA-r77w-qph3-7vf8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/graphql-python/graphql-core/commit/437dea102e92fdf05a2971ca76787c5a5bad875a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/graphql-python/graphql-core/commit/80ef435a1808fbbcc4aaac63ae76771a1c91002d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/graphql-python/graphql-core"
    },
    {
      "type": "WEB",
      "url": "https://github.com/graphql-python/graphql-core/releases/tag/v3.2.12"
    },
    {
      "type": "WEB",
      "url": "https://github.com/graphql-python/graphql-core/releases/tag/v3.3.0rc1"
    }
  ],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "GraphQL-core: Denial of service via comment tokens bypassing the parser\u0027s max_tokens limit",
  "upstream": [
    "GHSA-r77w-qph3-7vf8",
    "CVE-2026-75508"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

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.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.