GHSA-pw5q-rjx4-7f7p: High severity go/github.com/getarcaneapp/arcane/backend/v2 vulnerability
Summary A user holding the delegated users:update permission can reset the global administrator's password and take over the admin account. UpdateUser sets the target user's PasswordHash from the request body for ANY target with no comparison of caller-vs-target privilege. Because role assignment and role CRUD are deliberately gated by RequireGlobalAdmin, users:update is intended to sit BELOW admin (profile management); this finding defeats that separation.
Root Cause UpdateUser (handler backend/api/handlers/users.go:317-323) loads the target by ID and sets userModel.PasswordHash from the request body for any user, then userService.UpdateUser (userservice.go:174) simply tx.Saves — with NO actor-vs-target privilege comparison. The only IsGlobalAdmin guard (userservice.go:345) is a last-admin check inside DeleteUser, not the update path. Role assignment / role CRUD are RequireGlobalAdmin (backend/pkg/authz/permissions.go:27-33), proving users:update is intended below admin.
Impact Complete administrator account takeover (C:H/I:H/A:H) by any holder of the delegated users:update permission.
Proof of Concept 1. Admin delegates a custom "User Manager" role with users:update. 2. PUT /users/{adminId} with {"password":"attacker123"}. 3. POST /auth/login {"username":"arcane","password":"attacker123"} → admin session.
Attack Chain 1. Action: admin delegates custom role with users:update. Guard: role creation is RequireGlobalAdmin. Bypass: intended delegation (holder is meant to manage profiles, not seize admin). 2. Action: PUT /users/{adminId} {"password":"attacker123"}. Guard: RequirePermission(users:update) (users.go:154). Bypass: holder has it; no hierarchy check (users.go:317-323, userservice.go:174 unconditional Save). 3. Action: POST /auth/login as admin → admin session.
Bypass Evidence - users.go:317-323 sets PasswordHash for any target; userservice.go:174-194 has no actor/target privilege comparison. - Only IsGlobalAdmin hits are DeleteUser's last-admin guard and DTO flags (grep). - users:update is org-level, held by no built-in non-admin role (permissions.go:24).
Affected Versions <= 2.5.0.
Reported by zx (Jace) — GitHub: @manus-use
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/getarcaneapp/arcane/backend/v2to a version that resolves this vulnerability.Fixed in 2.6.0
Event History
Frequently Asked Questions
Who can exploit this issue?
Any authenticated user who holds the delegated `users:update` permission can exploit it. That permission is intended for lower-privilege profile management, not global administrator actions.
What does exploitation require?
The attacker needs the `users:update` permission and the ability to submit an UpdateUser request targeting the global administrator account. No administrator interaction is required.
What is the impact if exploitation succeeds?
The attacker can replace the global administrator's password, authenticate as that administrator, and obtain complete administrator account control. This can compromise confidentiality, integrity, and availability.
How can defenders determine whether they are exposed?
Review delegated or custom roles for the `users:update` permission and identify every account assigned those roles. Any such account may be able to change the password hash of any target user, including the global administrator.
What can be done while patching is not possible?
Remove or restrict the delegated `users:update` permission from non-global-administrator accounts. Limit access to accounts that can issue user-update requests until the update path enforces caller-versus-target privilege checks.