GHSA-x97m-qp5c-w9xj is a low-severity (CVSS 3.1) Information Exposure vulnerability in strawberry-graphql. O3 Security confirms whether GHSA-x97m-qp5c-w9xj is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Strawberry GraphQL: Default GraphiQL may expose HTTP headers in URLs
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-x97m-qp5c-w9xj.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-x97m-qp5c-w9xj plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 0 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
strawberry-graphqlReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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.
Affected Versions
- Affected:
strawberry-graphql >= 0.288.4, <= 0.315.3 - Patched: 0.315.4
The vulnerable behavior was introduced by the GraphiQL URL-sharing implementation in commit 9315ef80, first included in release 0.288.4.
Impact
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.
Technical Details
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=....
Fix
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.
Workarounds
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.
Credits
Reported by @lpschroer.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | strawberry-graphql | ≥ 0.288.4&&< 0.315.4 | 0.315.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for strawberry-graphql. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update strawberry-graphql to 0.315.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x97m-qp5c-w9xj is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-x97m-qp5c-w9xj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-x97m-qp5c-w9xj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-x97m-qp5c-w9xj in your dependencies?
O3 detects GHSA-x97m-qp5c-w9xj across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.