CVE-2026-80209: Fonoster through 0.22.7 Incorrect Authorization in the Identity UpdateWorkspace Handler

Published Aug 27, 2026
·
Updated

The updateWorkspace handler in mods/identity/src/workspaces/createUpdateWorkspace.ts in Fonoster through 0.22.7 invokes the gRPC callback with PERMISSIONDENIED 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.

Affected Software

1 affected component
fonoster<=0.22.7

Event History

Aug 27, 2026
CVE Published
via MITRE·02:50 PM
Data Sourced
via MITRE·02:50 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·05:20 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Who can exploit this issue?

Any authenticated user holding the base USER role can exploit it. The vulnerable Identity/UpdateWorkspace path is included in fullIdentityAccess, so access is not bound to membership in the workspace being renamed.

2

What access does an attacker need?

The attacker needs valid authentication and the ability to invoke the Identity/UpdateWorkspace gRPC handler. No workspace membership in the target workspace is required.

3

What is the practical impact?

An authenticated attacker can rename an arbitrary workspace in the deployment. The handler may return PERMISSION_DENIED even though the workspace update has already been committed.

4

How can administrators tell whether an attempted unauthorized rename succeeded?

Do not rely solely on a PERMISSION_DENIED response from the handler, because it can be issued after the database update. Verify the target workspace's current name and review workspace-change records if available.

5

What can be done while patching is unavailable?

Restrict access to the Identity/UpdateWorkspace gRPC operation to trusted users or disable it where operationally feasible. Monitor workspace names for unexpected changes, since base USER-role accounts are affected.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203