Arcane CVE-2026-96627

Requires an authenticated account that holds the delegated users:update permission - in Arcane this is not held by any built-in non-admin role, so an administrator must first create and assign a custom role (e.g. 'User Manager') containing users:update; this delegation is the key precondition and a realistic limiting factor, since deployments that never delegate users:update are not exploitable. Given that prerequisite, exploitation is remote, needs no user interaction, and requires no additional configuration: the attacker simply issues PUT /users/{adminId} with a password field to overwrite the global administrator's credential (handler backend/api/handlers/users.go:317-323 and user_service.go:174 perform an unconditional Save with no actor-vs-target privilege comparison). Affected in versions <= 2.5.0; fixed in 2.6.0.

This is a genuine high-priority privilege-escalation flaw (CWE-266) rather than an inflated high-CVSS issue. The input CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8) is internally consistent with the description and the source-code evidence: exploitation is network-reachable (AV:N), requires no user interaction (UI:N), is technically trivial (AC:L - two authenticated HTTP requests), and needs only low privilege (PR:L - any account holding the delegated users:update permission). The full C:H/I:H/A:H impact is justified because taking over the global administrator yields complete control of a Docker management plane (containers, images, networks, volumes), effectively control of the host. No EPSS score and no KEV status were provided in the input, so widespread-versus-targeted exploitation cannot be judged from the data. A working proof-of-concept is published in the GHSA advisory, so exploit knowledge is public, but public POC availability is NOT the same as confirmed active exploitation - there is no CISA KEV listing here. The one caveat that tempers raw CVSS: PR:L understates a real precondition - the victim administrator must first have delegated a custom role containing users:update to the attacker, which is not a default state; against a deployment that never delegates that permission, the flaw is not reachable.

An administrator delegates a custom 'User Manager' role carrying the users:update permission to a lower-trust operator, intending it for routine profile management. That operator sends PUT /users/{adminId} with {"password":"attacker123"}, overwriting the global administrator's password hash, then logs in as the admin account and gains full control of the Docker environment. A proof-of-concept with these exact requests is published in the GHSA advisory.