Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Strawberry's legacy graphql-ws subscription handler can retain task and subscription bookkeeping after a one-shot subscription has naturally sent its complete message. When the application configures maxsubscriptionsperconnection, the handler counts those completed operations in len(self.tasks). A client that uses distinct operation IDs can therefore reach the configured subscription limit even though the earlier subscriptions have already completed, causing subsequent legitimate subscriptions on the same persistent WebSocket connection to receive Subscription limit reached. This is a conditional connection-level availability and resource-accounting issue. It requires explicit use of the legacy graphql-ws protocol, a persistent WebSocket connection, one-shot subscriptions that naturally complete, and a configured maxsubscriptionsperconnection limit. It is not an unconditional issue in a default Strawberry installation and is distinct from the previously fixed…
Recommended action: Upgrade to 0.327.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PermissionExtension.resolve() evaluates the return value of haspermission() for truthiness on the synchronous path. supportssync only classifies a permission as asynchronous when haspermission is declared with async def (via inspect.iscoroutinefunction), so a plain def that returns an awaitable is treated as synchronous. An awaitable is always truthy, so the check passes even when it resolves to False and the protected resolver runs. The resolve path is chosen by the field resolver, not by the execution method, so any field with a synchronous resolver is affected under both executesync() and execute(). Permissions declared with async def haspermission(), or a plain def returning a boolean, are not affected. Details The affected code is PermissionExtension.resolve() in strawberry/permission.py. A permission attached to a field whose haspermission is a normal def returning an awaitable reaches this path; the awaitable is never awaited and its truthiness grants access.…
Recommended action: Upgrade to 0.326.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 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 payloads Impact An attacker can bypass security constraints to cause Application-level DOS. By staying…
Recommended action: Upgrade to 0.315.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 exploit Impact Since the validation happens before execution, an attacker can cheaply trigger this recursion error to exhaust server CPU cycles and thread/worker pools
Recommended action: Upgrade to 0.315.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.315.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.312.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. The graphql-transport-ws subprotocol handler is not affected, as it correctly gates subscription operations on a connectionacknowledged flag. However, both subprotocols are enabled by default in all framework integrations that support websockets, and the subprotocol is selected by the client via the Sec-WebSocket-Protocol header. Any application relying on onwsconnect for authentication or authorization is affected. Mitigation: Upgrade to the patched version, or explicitly disable the legacy graphql-ws subprotocol…
Recommended action: Upgrade to 0.312.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Summary A type confusion vulnerability exists in Strawberry GraphQL's relay integration that affects multiple ORM integrations (Django, SQLAlchemy, Pydantic). The vulnerability occurs when multiple GraphQL types are mapped to the same underlying model while using the relay node interface. Affected Components - Strawberry GraphQL relay integration - Specifically impacts implementations using: - Django integration - SQLAlchemy integration - Pydantic integration Technical Details The vulnerability manifests when: 1. Multiple GraphQL types inherit from relay.Node 2. These types are mapped to the same database model 3. The global node field is used for type resolution Example of vulnerable code: Security Impact When querying for a specific type using the global node field (e.g., FruitType:some-id), the resolver may incorrectly return an instance of a different type mapped to the same model (e.g., SpecialFruitType). This can lead to: 1. Information disclosure if the alternate…
Recommended action: Upgrade to 0.257.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Multipart file upload support as defined in the GraphQL multipart request specification was enabled by default in all Strawberry HTTP view integrations. This made all Strawberry HTTP view integrations vulnerable to CSRF attacks if users did not explicitly enable CSRF preventing security mechanism for their servers. Additionally, the Django HTTP view integration, in particular, had an exemption for Django's built-in CSRF protection (i.e., the CsrfViewMiddleware middleware) by default. In affect, all Strawberry integrations were vulnerable to CSRF attacks by default. Patches Version v0.243.0 is the first strawberry-graphql including a patch. Check out our documentation for additional details and upgrade instructions. References - Strawberry upgrade guide - Multipart Upload Security Implications Credits - Thomas Grainger - Arthur Bayr - Jonathan Ehwald
Recommended action: Upgrade to 0.243.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.