CVE-2026-59289

Overview

Spring for GraphQL is the GraphQL integration for the Spring portfolio, built on GraphQL Java. It wires a GraphQL engine into Spring MVC and WebFlux applications, maps schema fields to controller methods and data fetchers, and provides ready made integrations such as the Spring Data auto registration support, which exposes Query by Example and Querydsl repositories as GraphQL query fields, including Relay style Connection fields with cursor based pagination.

A Denial of Service (DoS) vulnerability (CVE-2026-59289) has been identified in the Spring Data pagination support of Spring for GraphQL, which allows attackers to request an arbitrarily large page from a repository backed Connection field and exhaust application memory or place heavy, prolonged load on the underlying datastore.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.

This issue affects applications that expose a Connection typed query field backed by a Spring Data repository through the auto registration support of Spring for GraphQL, for example through QueryByExampleDataFetcher or QuerydslDataFetcher, and that do not enforce additional query complexity checks.

Details

Module Info

• Product: Spring for GraphQL
• Affected packages: org.springframework.graphql:spring-graphql
• Affected versions: >=1.2.0 <=1.3.9, >=1.4.0 <=1.4.6, >=2.0.0 <=2.0.4
• GitHub repository: https://github.com/spring-projects/spring-graphql
• Published packages: https://central.sonatype.com/artifact/org.springframework.graphql/spring-graphql
• Package manager: Maven
• Fixed in:
• NES for Spring for GraphQL: nes-v1.2.16 (1.2.x), nes-v1.3.12 (1.3.x), and nes-v1.4.8 (1.4.x)
• OSS Spring for GraphQL: 2.0.5

Vulnerability Info

This High-severity vulnerability is found in the org.springframework.graphql:spring-graphql package in the Spring Data pagination support of Spring for GraphQL.

When a Connection typed query field is served by an auto registered repository data fetcher, the scrollable fetchers inside QueryByExampleDataFetcher and QuerydslDataFetcher resolve the pagination arguments of the incoming request and hand the resulting element count straight to the repository query. The count comes from the client supplied first or last argument, and the only fallback applied is a default that is used when the client supplies no count at all:

@Override
protected Iterable<R> getResult(FluentQuery.FetchableFluentQuery<R> queryToUse, DataFetchingEnvironment env) {
    ScrollSubrange range = RepositoryUtils.getScrollSubrange(env, this.cursorStrategy);
    int count = range.count().orElse(this.defaultCount);
    ScrollPosition position = (range.position().isPresent() ?
            range.position().get() : this.defaultPosition.apply(range.forward()));
    return queryToUse.limit(count).scroll(position);
}

this.defaultCount is only a default, seeded from the repository utilities:

static int defaultScrollCount() {
    return 20;
}

Because range.count() is populated directly from the request arguments and is never clamped, an unauthenticated caller who can reach the GraphQL endpoint can send a query such as one asking for the first two billion elements of a Connection field, and the fetcher will pass that limit to the datastore and attempt to materialize the returned window in memory. The same unbounded expression appears in the blocking and reactive scrollable fetchers of both QueryByExampleDataFetcher and QuerydslDataFetcher, so both the Query by Example and the Querydsl auto registration paths are reachable, in servlet and reactive applications alike. Repeated requests of this shape drive the application toward an OutOfMemoryError and keep the datastore busy building oversized result sets, denying service to legitimate users.

Mitigation

Only recent versions of Spring for GraphQL receive community support. Older lines are End-of-Life and will not receive public updates to address this issue.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported version of Spring for GraphQL.
• Enforce query complexity or pagination limits in front of the affected fields, for example with a maximum request size, an instrumentation that rejects oversized first and last arguments, or hand written data fetchers that clamp the requested count.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• No finder is named in the vendor advisory for this issue.