CVE-2026-80209 in Fonoster
Summary
by MITRE • 08/27/2026
The updateWorkspace handler in mods/identity/src/workspaces/createUpdateWorkspace.ts in Fonoster through 0.22.7 invokes the gRPC callback with PERMISSION_DENIED when createIsWorkspaceMember reports that the caller is not a member of the target workspace, but it does not return. Execution continues into prisma.workspace.update, which is scoped by the workspace reference alone, so the rename commits before the second callback is issued and the caller receives a permission error for a write that already succeeded. The gRPC interceptor in mods/common/src/identity/createAuthInterceptor.ts binds the workspace accessKeyId to the caller's token only for paths in workspaceResourceAccess or workspaceResourceOwnerOrAdminAccess, and Identity/UpdateWorkspace is listed in fullIdentityAccess, which the base USER role holds. Any authenticated user can therefore rename an arbitrary workspace in the deployment.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in Fonoster versions through 0.22.7 represents a critical authorization bypass rooted in flawed control flow and insufficient access validation within the identity management subsystem. Specifically, the issue resides in the updateWorkspace handler located at mods/identity/src/workspaces/createUpdateWorkspace.ts. The core technical flaw is an improper check-then-use pattern combined with asynchronous callback handling that allows state modification to occur before permission verification is finalized. When a user attempts to rename or modify workspace attributes, the system first invokes createIsWorkspaceMember to verify if the caller holds membership in the target workspace. If this check fails and reports that the caller is not a member, the code incorrectly proceeds to invoke the gRPC callback with a PERMISSION_DENIED status. However, rather than terminating execution immediately upon receiving this denial signal, the function continues its operational flow. This design error allows subsequent database operations to execute despite the lack of authorization.
The severity of this flaw is exacerbated by how the underlying data persistence layer handles scoping. The prisma.workspace.update operation relies solely on the workspace reference identifier for scoping purposes and does not re-validate ownership or membership at the point of execution. Consequently, even though the gRPC interceptor attempts to signal a permission error via callback, the database update commit has already been processed by this stage. This race condition-like behavior results in a state where the rename operation is successfully committed to the database before the caller receives the rejection notification. The user interface or client application may display an error message indicating failure, yet the backend state reflects that the unauthorized change was applied. This discrepancy between reported status and actual system state creates confusion for administrators and undermines the integrity of access control logs which might not accurately reflect successful unauthorized modifications if they rely solely on gRPC response codes rather than database audit trails.
The root cause extends beyond this single handler to a broader architectural weakness in the authentication interceptor logic found in mods/common/src/identity/createAuthInterceptor.ts. This component is responsible for binding workspace access keys and validating permissions based on predefined role hierarchies. The interceptor restricts certain operations by checking if they fall under specific scopes such as workspaceResourceAccess or workspaceResourceOwnerOrAdminAccess. However, the Identity/UpdateWorkspace endpoint is categorized under fullIdentityAccess. In Fonoster’s default configuration, this scope is granted to the base USER role. This means that any authenticated user possesses the necessary permissions at the interceptor level to invoke this handler without needing explicit membership in the target workspace. The combination of overly permissive role assignments and the lack of granular checks within the business logic layer allows an attacker who has valid credentials for one account to arbitrarily rename or modify configurations of workspaces they do not own, provided those workspaces exist on the same deployment instance.
From a threat modeling perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization. The attacker can leverage this flaw for unauthorized data modification, potentially disrupting organizational workflows by renaming critical project spaces or causing confusion among team members who rely on consistent workspace naming conventions. Furthermore, because the operation succeeds despite the error response, it may facilitate persistence of malicious configurations if an adversary uses this method to alter settings that affect downstream services dependent on specific workspace identifiers. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1078 Valid Accounts and potentially T1496 Local Data Staging or T1530 Data from Information Repositories depending on the subsequent use of the renamed workspace for exfiltration or lateral movement within a compromised environment. The ability to modify resources without proper ownership verification is a classic indicator of broken object level authorization, which remains one of the most prevalent and dangerous web application vulnerabilities according to OWASP guidelines.
Mitigation strategies must address both the immediate code defect and the underlying architectural permissions model. First, developers should refactor the updateWorkspace handler to ensure that permission checks are strictly enforced before any database mutations occur. The gRPC callback indicating PERMISSION_DENIED must trigger an early return statement or throw a synchronous exception that halts further execution of the function body. It is imperative to decouple the response signaling from the state modification logic so that no write operations can proceed if authorization fails at any stage. Second, the access control model requires review. The Identity/UpdateWorkspace endpoint should not be included in fullIdentityAccess for the base USER role unless there is a specific business requirement allowing users to modify arbitrary workspaces. Instead, it should be restricted to workspaceResourceOwnerOrAdminAccess or similar scopes that verify actual ownership or elevated privileges within the target context. Implementing middleware-level checks that validate membership prior to invoking handler logic would provide an additional layer of defense in depth.
Administrators running affected versions should immediately upgrade Fonoster to a patched version where these control flow and permission issues have been resolved. In environments where upgrading is not immediately feasible, network segmentation or WAF rules could potentially be configured to restrict access to the identity management endpoints based on IP reputation or specific header validations, although this is less effective than fixing the application logic. Additionally, enabling comprehensive audit logging that records both gRPC responses and database transaction outcomes can help detect instances where a permission error was returned but a write operation succeeded, allowing for faster incident response and forensic analysis. Regular security code reviews focusing on asynchronous control flow and authorization boundaries are recommended to prevent similar vulnerabilities in future development cycles.