CVE-2026-45739Low· 3.1▾ SunlitStrawberry GraphQL: Default GraphiQL may expose HTTP headers in URLs
▾ Sunlit zone — Low / medium · no exploitation signal
impact 17.1 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 13.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
0.2%
Strawberry's bundled GraphiQL template wrote values from the GraphiQL headers editor into the browser URL query string. If a user entered a sensitive header, such as Authorization: Bearer <token>, the value could become visible in browser history, copied links, and server/proxy/CDN access logs after a page reload or shared request.
strawberry-graphql >= 0.288.4, <= 0.315.3The vulnerable behavior was introduced by the GraphiQL URL-sharing implementation in commit 9315ef80, first included in release 0.288.4.
Applications that expose Strawberry's default GraphiQL IDE may leak sensitive HTTP header values entered by users into the GraphiQL headers editor. The default IDE is enabled by graphql_ide="graphiql" across Strawberry HTTP integrations unless disabled or replaced by the application.
The exposure is limited to the browser-based IDE. GraphQL query execution is not affected, and this issue does not allow an attacker to directly execute operations or bypass authorization. Practical exploitation requires a user to enter a secret into the GraphiQL headers editor and then expose the resulting URL, for example by refreshing the page, copying the URL, sharing the URL, or causing the URL to be recorded by logging infrastructure.
The bundled strawberry/static/graphiql.html template parsed URL query parameters into a parameters object and used those values to initialize GraphiQL state. It also updated the URL on editor changes using history.replaceState.
Before the fix, header values were handled like shareable query text and variables:
const [headers, setHeaders] = React.useState(parameters.headers);
function onEditHeaders(newHeaders) {
setHeaders(newHeaders);
updateURL({ headers: newHeaders });
}
This meant arbitrary header text entered into the IDE could be serialized into ?headers=....
The GraphiQL template no longer calls updateURL from onEditHeaders. Query and variable URL sharing remain unchanged, and existing URLs with headers=... can still initialize the headers editor. Header persistence via GraphiQL's own shouldPersistHeaders: true behavior remains enabled, so newly edited headers can still persist locally without being placed in the URL.
Until a patched version can be used, applications can mitigate this issue by disabling the bundled IDE in production:
GraphQLRouter(schema, graphql_ide=None)
Equivalent graphql_ide=None configuration is available in Strawberry's other HTTP integrations.
Applications can also provide a custom GraphiQL template that does not serialize header values into the URL.
Reported by @lpschroer.
strawberry-graphql >= 0.288.4, < 0.315.4Upgrade to a patched release:
strawberry-graphql 0.315.4Connected by shared product, vendor, weakness, or advisory.
CVE-2026-47706Medium· 5.3Strawberry GraphQL has a Circular Fragment Reference DOS
CVE-2026-47707Medium· 5.3Strawberry GraphQL's Bypass of MaxAliasesLimiter via Fragment Spreads leading to GraphQL Alias Amplification
CVE-2025-22151Low· 3.7Strawberry GraphQL has type resolution vulnerability in node interface that allows potential data leakage through incorrect type resolution