GHSA-PW5Q-RJX4-7F7P
Vulnerability from github – Published: 2026-10-16 21:15 – Updated: 2026-10-16 21:15Summary
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 (user_service.go:174) simply tx.Saves — with NO actor-vs-target privilege comparison. The only IsGlobalAdmin guard (user_service.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
- Admin delegates a custom "User Manager" role with
users:update. PUT /users/{adminId}with{"password":"attacker123"}.POST /auth/login {"username":"arcane","password":"attacker123"}→ admin session.
Attack Chain
- Action: admin delegates custom role with
users:update. Guard: role creation isRequireGlobalAdmin. Bypass: intended delegation (holder is meant to manage profiles, not seize admin). - Action:
PUT /users/{adminId}{"password":"attacker123"}. Guard:RequirePermission(users:update)(users.go:154). Bypass: holder has it; no hierarchy check (users.go:317-323,user_service.go:174unconditional Save). - Action:
POST /auth/loginas admin → admin session.
Bypass Evidence
users.go:317-323setsPasswordHashfor any target;user_service.go:174-194has no actor/target privilege comparison.- Only
IsGlobalAdminhits areDeleteUser's last-admin guard and DTO flags (grep). users:updateis 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": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/getarcaneapp/arcane/backend/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-96627"
],
"database_specific": {
"cwe_ids": [
"CWE-266",
"CWE-269"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-16T21:15:03Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\nA user holding the delegated `users:update` permission can reset the global administrator\u0027s password and take over the admin account. `UpdateUser` sets the target user\u0027s `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.\n\n## Root Cause\n`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` (`user_service.go:174`) simply `tx.Save`s \u2014 with NO actor-vs-target privilege comparison. The only `IsGlobalAdmin` guard (`user_service.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.\n\n## Impact\nComplete administrator account takeover (C:H/I:H/A:H) by any holder of the delegated `users:update` permission.\n\n## Proof of Concept\n1. Admin delegates a custom \"User Manager\" role with `users:update`.\n2. `PUT /users/{adminId}` with `{\"password\":\"attacker123\"}`.\n3. `POST /auth/login {\"username\":\"arcane\",\"password\":\"attacker123\"}` \u2192 admin session.\n\n## Attack Chain\n1. 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).\n2. Action: `PUT /users/{adminId}` `{\"password\":\"attacker123\"}`. Guard: `RequirePermission(users:update)` (`users.go:154`). Bypass: holder has it; no hierarchy check (`users.go:317-323`, `user_service.go:174` unconditional Save).\n3. Action: `POST /auth/login` as admin \u2192 admin session.\n\n## Bypass Evidence\n- `users.go:317-323` sets `PasswordHash` for any target; `user_service.go:174-194` has no actor/target privilege comparison.\n- Only `IsGlobalAdmin` hits are `DeleteUser`\u0027s last-admin guard and DTO flags (grep).\n- `users:update` is org-level, held by no built-in non-admin role (`permissions.go:24`).\n\n## Affected Versions\n`\u003c= 2.5.0`.\n\nReported by **zx (Jace)** \u2014 GitHub: @manus-use",
"id": "GHSA-pw5q-rjx4-7f7p",
"modified": "2026-10-16T21:15:03Z",
"published": "2026-10-16T21:15:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getarcaneapp/arcane/security/advisories/GHSA-pw5q-rjx4-7f7p"
},
{
"type": "WEB",
"url": "https://github.com/getarcaneapp/arcane/pull/3426"
},
{
"type": "WEB",
"url": "https://github.com/getarcaneapp/arcane/commit/21ea962f86d967dac8ae02a050f6e5f043d10fa1"
},
{
"type": "PACKAGE",
"url": "https://github.com/getarcaneapp/arcane"
},
{
"type": "WEB",
"url": "https://github.com/getarcaneapp/arcane/releases/tag/backend/v2.6.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Arcane: Delegated users:update permission allows admin account takeover via password reset (no privilege-hierarchy check)"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.