Strawberry GraphQL patches WebSocket subscription auth bypass

TL;DR — Strawberry GraphQL’s legacy graphql-ws handler can process subscription start messages without a completed connection_init, bypassing on_ws_connect auth and exposing subscription data to unauthenticated clients.

What happened

Strawberry GraphQL is a Python library for building GraphQL APIs, including WebSocket-based subscriptions. CVE-2026-35523 reports a High-severity authentication bypass on WebSocket subscription endpoints: Strawberry’s legacy graphql-ws subprotocol handler does not verify that the connection_init handshake has completed before it processes start (subscription) messages.

Per the CVE record and linked GitHub advisory, a remote attacker can select the legacy graphql-ws subprotocol and send a start message directly (without sending connection_init), which skips the on_ws_connect authentication hook entirely.

This is a recurring class of real-world failure: WebSocket protocol negotiation plus “hook-based” auth is easy to get wrong, and clients choosing behavior via Sec-WebSocket-Protocol can create bypass paths that won’t show up in typical HTTP-only auth testing.

Who is impacted

• Projects using strawberry-graphql versions < 0.312.3.
• Any Strawberry deployment exposing WebSocket subscriptions where the service relies on on_ws_connect for authentication/authorization.
• Deployments that allow the legacy graphql-ws subprotocol (the advisory notes both graphql-ws and graphql-transport-ws are enabled by default in framework integrations that support websockets, and the client selects the subprotocol via Sec-WebSocket-Protocol).

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.

  "This vulnerability is fixed in 0.312.3."

• If you cannot upgrade immediately, use the mitigation described in the advisory to reduce exposure:

  "Mitigation: Upgrade to the patched version, or explicitly disable the legacy graphql-ws subprotocol by setting subscription_protocols=[GRAPHQL_TRANSPORT_WS_PROTOCOL] on your GraphQL view/router."

• Treat this as a potential unauthorized-access scenario for subscription data:
  • review WebSocket access logs for connections negotiating graphql-ws and immediately sending subscription start messages without a prior connection_init
  • rotate/expire any sensitive tokens or credentials that could have been exposed via subscription payloads, based on what your schema publishes over subscriptions