CVE-2026-107728 in strawberry-graphql
Summary
by MITRE • 10/09/2026
Strawberry GraphQL is a library for creating GraphQL APIs. From 0.217.0 until 0.326.1, PermissionExtension.resolve() on a synchronous field resolver evaluates the result of has_permission() for truthiness. When a custom permission declares has_permission() as a normal function but returns an awaitable, supports_sync does not classify it as asynchronous, the awaitable is not awaited, and its inherently truthy object value permits the protected resolver to run even when the result would resolve to false. This affects synchronous field resolvers under both execute_sync() and execute(); permissions declared with async def has_permission() and synchronous permissions returning a boolean are not affected. This issue is fixed in version 0.326.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The Strawberry GraphQL library, widely used for constructing Python-based GraphQL APIs, contained a critical logic flaw within its PermissionExtension component affecting versions from 0.217.0 through 0.326.1. This vulnerability specifically impacts the resolution of synchronous field resolvers when custom permission classes are employed to enforce access control policies. The core issue stems from an incorrect evaluation mechanism used by the resolve method, which determines whether a user is authorized to execute a specific resolver based on the return value of the has_permission function defined within the permission class.
The technical flaw arises from how the library distinguishes between synchronous and asynchronous execution contexts for custom permissions. When a developer defines a permission using an async def has_permission() coroutine or a standard synchronous function that returns a boolean, the system correctly handles the authorization check. However, if a developer implements has_permission as a regular synchronous function but inadvertently returns an awaitable object such as a Task, Future, or other non-boolean truthy value, the library fails to recognize this as an asynchronous operation. Consequently, the supports_sync flag remains false for async detection purposes, yet because the resolver is classified as synchronous in the broader context, the code path does not invoke the await keyword on the returned object.
This oversight leads to a severe authorization bypass scenario. Since Python treats most non-empty objects and instances as truthy values in boolean contexts, the unresolved awaitable object evaluates to true during the permission check. As a result, the PermissionExtension grants access to the protected resolver even though the actual logical outcome of the permission logic would have been false if it had been properly awaited. This means that attackers or unauthorized users can bypass security controls simply by exploiting this type confusion between synchronous execution and asynchronous return values within custom permission classes.
The operational impact of this vulnerability is significant, as it undermines the integrity of access control mechanisms in GraphQL APIs built with Strawberry. Systems relying on these permissions for sensitive data protection may expose restricted endpoints to unintended actors. This aligns with CWE-284 Improper Access Control and CWE-756 Missing Custom Error Handling or Protection Mechanism, where the failure to correctly process security-critical logic leads to unauthorized access. In terms of MITRE ATT&CK framework mapping, this vulnerability facilitates Initial Access by allowing attackers to bypass authentication checks that should restrict entry to specific resources or functions within the application.
To mitigate this risk, organizations using affected versions must upgrade immediately to Strawberry GraphQL version 0.326.1 or later, where the resolve method has been corrected to properly handle awaitable returns from synchronous permission definitions. For environments unable to patch immediately, developers should audit their custom PermissionExtension implementations to ensure that any function returning an awaitable is defined as async def rather than a standard function. Additionally, implementing strict type checking and ensuring all permission checks explicitly return boolean values can prevent this class of logic errors in future development cycles.