Strawberry-Graphql (0.217.0 - 0.326.0) - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/strawberry-graphql-0.217.0---0.326.0/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioFri, 09 Oct 2026 15:27:56 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgStrawberry GraphQL Permission Bypass via Awaitable Truthinesshttps://feed.craftedsignal.io/briefs/2026-10-strawberry-graphql-bypass/Fri, 09 Oct 2026 15:27:56 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-10-strawberry-graphql-bypass/Strawberry GraphQL's PermissionExtension incorrectly handles synchronous custom permission checks that return awaitable objects, allowing unauthorized access to protected fields due to Python's truthy evaluation of unawaited coroutines.Strawberry GraphQL (versions 0.217.0 through 0.326.0) contains an authorization bypass vulnerability within PermissionExtension.resolve() in strawberry/permission.py. When a developer defines a custom permission class with a has_permission method using a standard def (instead of async def) that returns an awaitable result (such as a coroutine), the framework fails to await the result or check its resolved value. Because Python evaluates an unawaited awaitable object as truthy, the authorization check unconditionally grants access, bypassing intended security controls on the protected GraphQL field.

This issue affects any application using custom permission classes where has_permission does not return a direct boolean or utilize async def. Standard async def permissions or those returning explicit boolean values remain unaffected. The flaw impacts both execute_sync() and execute() paths for fields utilizing synchronous resolvers.

Attack Chain

  1. Attacker identifies a GraphQL field protected by a custom strawberry.permission.BasePermission class.
  2. The custom permission class is misconfigured such that has_permission is defined as a synchronous def that returns a coroutine object rather than a boolean.
  3. Attacker sends a standard GraphQL query requesting data from the protected field.
  4. The Strawberry GraphQL engine invokes PermissionExtension.resolve() during the resolution of the requested field.
  5. PermissionExtension.resolve() checks the truthiness of the returned object from has_permission().
  6. Python evaluates the unawaited coroutine as True (truthy).
  7. The framework treats the authorization as granted, bypassing the logic intended to block the request.
  8. The underlying field resolver is executed, and the sensitive data is returned in the GraphQL response to the attacker.

Impact

Successful exploitation results in unauthorized access to GraphQL fields intended to be protected by custom permission logic. This may lead to the exposure of sensitive data, unauthorized state changes, or the bypass of business logic checks, depending on what the specific permission-protected resolver performs. The impact is limited to applications that implement custom permission classes matching the vulnerable has_permission function signature.

Recommendation

Prioritize auditing custom permission classes within your Strawberry GraphQL implementation to identify any has_permission definitions that return awaitables rather than explicit boolean values.

  • Upgrade strawberry-graphql to a version containing the fix for CVE-2026-107728.
  • Review all classes inheriting from strawberry.permission.BasePermission to ensure has_permission functions are either standard methods returning booleans or are explicitly defined as async def for asynchronous logic.
  • If using asynchronous logic, verify that the application properly utilizes resolve_async() or ensure all permission checks are correctly awaited before boolean evaluation.
]]>highadvisoryauthorization-bypassgraphqlapplication-vulnerability