Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-27T17:20:50.423Z",
  "pubdate": "2026-08-27T17:20:50.423Z",
  "executiveSummary": "The Fonoster identity module contains an authorization bypass vulnerability affecting the updateWorkspace handler. The flaw stems from improper control flow handling during access validation, where an execution path continues after an authorization check failure. This vulnerability allows any authenticated user to perform unauthorized modification of arbitrary workspaces within a Fonoster deployment. The impact is significant, as it enables unauthorized renaming of workspaces, leading to potential service disruption or masquerading attacks. The issue is present in versions up to and including 0.22.7. Successful exploitation requires a valid user session, but no elevated privileges are necessary, as the affected function is included in the base USER role access scope.",
  "technicalDetails": "The vulnerability is located in the updateWorkspace handler within mods/identity/src/workspaces/createUpdateWorkspace.ts. The core issue is an insufficient authorization check mechanism that fails to terminate process execution upon detecting a permission violation. When the application invokes createIsWorkspaceMember to verify if the caller is a member of the target workspace, the system correctly identifies unauthorized access attempts and issues a PERMISSION_DENIED gRPC callback. However, the handler lacks an explicit return statement after triggering this callback. Consequently, the execution thread continues into the subsequent database operation, prisma.workspace.update.\nThe prisma.workspace.update operation is scoped strictly by the provided workspace reference. Because the authorization verification logic does not effectively block the progression of the operation, the prisma update command executes successfully, overwriting the workspace data before the gRPC response is finalized. The caller ultimately receives a permission error message, but the underlying write operation has already been committed to the database. This race condition between the notification and the data mutation creates a functional bypass of the intended security constraints.\nThe susceptibility to this exploit is further compounded by the configuration in mods/common/src/identity/createAuthInterceptor.ts. The Identity/UpdateWorkspace function is incorrectly categorized within fullIdentityAccess. Unlike paths restricted by workspaceResourceAccess or workspaceResourceOwnerOrAdminAccess, which implement more granular check logic, the fullIdentityAccess path is accessible to the base USER role. Therefore, any authenticated user—regardless of their membership status in a target workspace—can trigger this update flow. An attacker only needs to provide the target workspace identifier and the desired new name to manipulate metadata. The consequence is an authorization bypass that allows unauthorized users to modify the state of workspaces they do not own or manage, undermining the multi-tenant isolation model of the Fonoster platform."
}