GHSA-3h96-34p3-xm76

What it actually does

GraphQL-Ruby can be forced to spend excessive CPU and memory parsing oversized GraphQL request bodies because the `max_query_string_tokens` limit does not count comment tokens. An attacker can submit a syntactically valid GraphQL document padded with a very large number of comments, causing the Ruby lexer to continue processing input beyond the intended token ceiling. This affects deployments using GraphQL-Ruby versions where `max_query_string_tokens` is enabled and handled by the Ruby lexer; GraphQL-CParser is not affected.

Why it matters to the business

Public or authenticated GraphQL endpoints may be vulnerable to application-layer denial of service. Successful exploitation can degrade API performance, increase worker saturation, raise infrastructure costs, and cause partial or full outage of services that depend on GraphQL request handling. Although no known exploitation or KEV listing is reported, the flaw is straightforward to abuse where affected GraphQL-Ruby versions are exposed, so internet-facing GraphQL APIs should be patched promptly.

How an attack unfolds

An attacker identifies an application exposing a GraphQL endpoint backed by GraphQL-Ruby. They craft a GraphQL request that includes a large number of comment tokens, typically lines beginning with `#`, while keeping the meaningful query content small enough to appear within configured query limits. Because vulnerable versions do not count those comments toward `max_query_string_tokens`, the parser continues lexing and processing far more input than intended. Repeated requests can consume application worker CPU and memory, exhaust thread or process pools, increase queue latency, and make the GraphQL service unavailable to legitimate users.

How to fix it

Upgrade GraphQL-Ruby to a patched release for the 2.x branch in use, preferably the latest available 2.x patch version. The vulnerable behavior was introduced with `max_query_string_tokens` in v2.3.1, and each supported 2.x series received a patch release that counts comment tokens correctly. If immediate upgrade is not possible, mitigate by enforcing strict HTTP request body size limits at the reverse proxy, application server, or API gateway; rate-limit GraphQL requests by source and identity; require authentication for GraphQL access where feasible; lower request timeouts; and consider using GraphQL-CParser where compatible, as it is not affected by this issue.

How to confirm the fix worked

Confirm the deployed `graphql` Ruby gem version is a patched release and that application dependencies have been rebuilt and redeployed. Review lockfiles such as `Gemfile.lock` and runtime package inventories to ensure vulnerable GraphQL-Ruby versions are no longer active. Validate behavior in a non-production environment by submitting a GraphQL request containing many comment lines and confirming it is rejected quickly once the configured token limit is reached. Also verify upstream controls such as request body limits, rate limits, and application timeouts are active on all GraphQL endpoints.

Typical attack path

1. Discover a GraphQL endpoint, commonly `/graphql`, through application behavior, documentation, JavaScript bundles, or API probing.
2. Confirm the endpoint accepts GraphQL POST requests and is parsed by GraphQL-Ruby.
3. Generate a GraphQL document containing an excessive number of comment lines or comment tokens mixed with a minimal valid operation.
4. Send one or many oversized comment-heavy requests to the endpoint.
5. Cause the Ruby lexer and application workers to spend excessive resources processing input that should have been rejected by the token limit.
6. Repeat or parallelize requests to sustain service degradation or outage.

How to detect it

Look for evidence of application-layer denial-of-service attempts against GraphQL endpoints. Useful log sources include reverse proxy access logs, web application firewall logs, API gateway logs, Rails or application logs, APM traces, container metrics, and process-level CPU and memory telemetry. Search for spikes in large `POST` requests to GraphQL routes, repeated requests with unusually high request-body sizes, payloads containing many GraphQL comment lines beginning with `#`, increased request duration, worker timeouts, 499/500/502/503/504 responses, and elevated CPU or memory in Ruby application processes. If request bodies are not logged, correlate abnormal body sizes, content lengths, request durations, source IP concentration, and GraphQL parse or timeout errors around the same time window. Because no public exploit maturity is reported, detection should focus on behavioral indicators rather than a single fixed exploit string.

• POST /graphql
• max_query_string_tokens
• GraphQL::ParseError
• GraphQL::ExecutionError
• GraphQL::Execution::Timeout
• Content-Type: application/graphql
• Content-Type: application/json
• #
• # query
• # mutation
• Gemfile.lock
• graphql (2.3.1)

What your security team should do

• Inventory all applications using the GraphQL-Ruby gem, especially internet-facing GraphQL APIs.
• Prioritize upgrade of GraphQL-Ruby 2.x deployments that enabled `max_query_string_tokens` and use the Ruby lexer.
• Apply reverse proxy or API gateway request body size limits for GraphQL endpoints while patching is underway.
• Add or tune rate limits for repeated large POST requests to GraphQL routes.
• Monitor GraphQL endpoint latency, request body size, application worker saturation, memory growth, and timeout/error rates for signs of abuse.
• Review logs for unusually large GraphQL requests containing excessive `#` comment lines or repeated parsing failures.
• If GraphQL-CParser is already used, confirm it is active in production and document the reduced exposure.