CVE-2026-107728: Authorization Bypass in Strawberry GraphQL Permission Validation

Strawberry GraphQL is a widely utilized Python library designed to build GraphQL APIs. The framework supports validating fields through permission classes, which check if the requesting user possesses the required authorizations before executing the corresponding field resolvers. This mechanism supports both synchronous and asynchronous modes of operation.

Between versions 0.217.0 and 0.326.1, a flaw exists in how the library handles synchronous field permission checks that return awaitable objects. The vulnerability allows an unauthenticated or unauthorized remote attacker to bypass permission validations. The flaw originates in the PermissionExtension.resolve() method, which performs direct truthiness checks on results returned from synchronous permission functions.

This vulnerability introduces a risk of unauthorized data disclosure, as custom permission decorators can be silently bypassed. Field resolvers that were intended to be private or restricted become accessible to any client.

The vulnerability is caused by a design discrepancy in Python's evaluation of coroutine objects coupled with the limitation of the supports_sync utility in Strawberry GraphQL. The library checks the asynchronous status of a permission class via inspect.iscoroutinefunction(permission.has_permission). If a developer defines the has_permission method using a standard synchronous declaration (def), this check evaluates to False.

Consequently, execution is routed through the synchronous path inside PermissionExtension.resolve(). If the developer's synchronous implementation returns an unawaited coroutine—for example, by calling an internal asynchronous function or external database wrapper without an asynchronous loop—the permission class returns a coroutine object instead of a boolean value.

In Python, all coroutines and awaitable objects evaluate to True when evaluated in a boolean context. The synchronous resolver checks truthiness using 'if not permission.has_permission(...)'. Because the returned coroutine object evaluates to True, the if statement evaluates to False, skipping the unauthorized logic path. The library assumes the check succeeded and executes the resolver, resulting in an authorization bypass.

Here is a visual mapping of the vulnerable execution flow:

The vulnerability resides in the validation path of strawberry/permission.py. When checking permissions, the code originally executed the permission verification directly within an 'if not' statement.

Below is the vulnerable implementation within strawberry/permission.py:

def resolve(self, next_, source, info, **kwargs) -> Any:
    for permission in self.permissions:
        # Vulnerable: If has_permission returns a coroutine, 
        # 'not coroutine' is evaluated, which is always False.
        if not permission.has_permission(source, info, **kwargs):
            return self._on_unauthorized(permission)
    return next_(source, info, **kwargs)

The fix introduced in version 0.326.1 checks if the return value of has_permission is awaitable. If inspect.isawaitable(has_permission) returns True in a synchronous context, the system raises an exception rather than proceeding.

Below is the patched implementation:

def resolve(self, next_, source, info, **kwargs) -> Any:
    for permission in self.permissions:
        has_permission = permission.has_permission(source, info, **kwargs)
 
        # Patched: Validate if an awaitable was returned in sync context
        if inspect.isawaitable(has_permission):
            # Close the coroutine to prevent resource leaks
            if inspect.iscoroutine(has_permission):
                has_permission.close()
 
            # Fail closed by throwing an explicit exception
            raise PermissionReturnedAwaitableInSyncContextError(permission)
 
        if not has_permission:
            return self._on_unauthorized(permission)
 
    return next_(source, info, **kwargs)

The fix ensures that any attempt to return an awaitable object inside a synchronous resolution path raises a PermissionReturnedAwaitableInSyncContextError exception. This causes the request to fail closed, preventing exposure of sensitive fields.

An attacker can exploit this bypass if a custom permission class evaluates authorization synchronously but delegates to asynchronous helpers. The exploit requires no special privileges and is executed over the network by sending a standard GraphQL query.

Below is a demonstration of how a vulnerable implementation behaves. The permission class is defined synchronously, but mistakenly returns an unawaited coroutine:

class VulnerableBypassPermission(BasePermission):
    message = "Unauthorized Access"
 
    def has_permission(self, source, info, **kwargs) -> Any:
        async def verify_user():
            # This logic should return False to deny access
            return False
        
        # Returns the coroutine object itself
        return verify_user()

When a request is submitted to the server for a field protected by VulnerableBypassPermission, the engine resolves the field synchronously. Because the returned coroutine object is inherently truthy, the bypass is completed, and the backend resolves the field despite the logic within verify_user evaluating to False.

The impact of this vulnerability is classified as High, with a CVSS v3.1 base score of 7.5. The vulnerability allows complete bypass of application-level access controls designed to secure specific GraphQL fields. An attacker can access sensitive information, administrative fields, or trigger operations they are unauthorized to execute.

Because the bypass occurs silently without logging an error or exception, detecting the exploitation via standard application logs can be difficult unless the application monitors the exact types of objects returned by permissions. The exploitation complexity is low, requiring only standard GraphQL query structures.

There is no integrity or availability impact as the flaw is an information leakage and access bypass. However, if the field resolver performs write operations (such as mutations executing under synchronous resolvers), integrity impact could also occur depending on the specific implementation.

To mitigate CVE-2026-107728, developers must upgrade the strawberry-graphql package to version 0.326.1 or higher. The upgraded library implements defensive checks to block the synchronous execution of awaitable objects.

For legacy deployments where immediate patching is not possible, developers must audit all BasePermission subclasses. Ensure that any has_permission function using standard def returns a primitive boolean. If asynchronous functions must be invoked, the method should be redeclared as async def.

A Semgrep rule can automate the identification of vulnerable patterns. The rule should flag any synchronous has_permission function that returns calls to functions known to return coroutines or awaitables.