CVE-2026-96627

Executive Summary

CVE-2026-96627 is a privilege-escalation and account-takeover vulnerability in Arcane, an open-source web interface for managing Docker containers, images, networks, and volumes. Prior to version 2.6.0, the UpdateUser handler in backend/api/handlers/users.go fails to compare the privilege of the caller against the privilege of the target account when setting a password hash. As a result, any user holding the delegated users:update permission can reset the password of the global administrator and authenticate as that account, achieving complete administrative takeover of the Arcane instance (CVSS 8.8). The flaw is fixed in version 2.6.0, though that claim originates from a single advisory source and is not independently confirmed.

Technical Analysis

The vulnerability is a classic server-side authorization failure (CWE-266, Incorrect Privilege Assignment / improper privilege boundary enforcement) located in the user-management API of the Arcane backend. According to the NVD description, the UpdateUser handler in backend/api/handlers/users.go sets the PasswordHash field for any user object targeted by the request, without verifying whether the requesting principal's privilege level matches or exceeds that of the target account.

Arcane uses a delegated/permission model in which an operator can be granted discrete capabilities such as users:update without being a full administrator. The intended security invariant is that a principal may only modify accounts of equal or lower privilege, and that only a global administrator should be able to alter the global administrator account. The UpdateUser handler violates this invariant in two ways:

1. No caller-vs-target privilege comparison. The handler authenticates the caller and checks for the users:update permission, but does not evaluate whether the caller is authorized to act on the specific target account. A delegated user with users:update can therefore supply the identifier of the global administrator account.
2. Password hash is a directly writable field. Because the update payload can carry a PasswordHash value, the caller can overwrite the administrator's stored credential with a value they control. This converts an authorization gap into a full credential-substitution primitive rather than a mere attribute change.

The attack surface is the authenticated HTTP API surface of the Arcane management interface. Exploitation requires network reachability to the Arcane service and a low-privileged authenticated session with the delegated permission — matching the CVSS vector (AV:N/AC:L/PR:L/UI:N), which rates complexity as low and requires no user interaction. Confidentiality, integrity, and availability impacts are all High: control of the global administrator account grants the ability to read and modify every Docker resource Arcane manages, including container images, volumes, and network definitions, and to reconfigure or destroy workloads. The scope is rated Unchanged because the impact is contained within the Arcane application and the Docker host it manages.

No proof-of-concept, exploit code, or Nuclei template is publicly available. The precise request schema, endpoint path, and the means by which a PasswordHash is submitted are not disclosed in the advisory text, and this report does not speculate about them. The core mechanism — an authenticated API call that writes a password hash to a higher-privileged account — is fully established by the description.

Exploitation Scenarios

The attack chain below is derived strictly from the NVD description and general reasoning about the vulnerability class. No public PoC exists; the chain is inferred from the described flaw.

1) Reconnaissance / target identification. An attacker obtains a low-privileged Arcane account, either through legitimate provisioning by an administrator who delegates the users:update permission, through credential reuse against a weakly protected operator account, or through any other means of gaining an authenticated foothold. The attacker confirms the Arcane version is prior to 2.6.0 and enumerates accounts to identify the global administrator (for example, the default or primary administrative identity).

2) Triggering the flaw. Using the authenticated session and its delegated users:update permission, the attacker issues a user-update request against the global administrator account, supplying a password hash of the attacker's choosing. The UpdateUser handler accepts the request because it checks only that the caller holds users:update — it never compares the caller's privilege to the target's. The write succeeds and the administrator's stored PasswordHash is replaced.

3) Payload / execution. The "payload" is the attacker-controlled password hash embedded in a normal privileged API operation. There is no memory corruption or injection step: the authorization flaw itself is the execution primitive. Once the hash is set, the attacker authenticates to Arcane using the known plaintext that corresponds to the submitted hash.

4) Post-exploitation. The attacker is now the global administrator. From that position they can create or modify other administrator and delegated accounts, alter any Docker container, image, network, or volume managed by Arcane, deploy malicious container images, expose internal services, or mount host resources depending on how the managed Docker environment is configured. They can also persist by minting additional accounts and by exfiltrating registry credentials or environment secrets exposed through container configuration.

Impact Assessment

This is a high-severity authenticated privilege-escalation flaw (CVSS 3.1 base 8.8). The AV:N metric reflects that the flaw is reachable over the network through the Arcane API; AC:L indicates the attacker needs no special conditions beyond a valid low-privileged session; PR:L reflects that only a delegated users:update holder is required; UI:N means no victim action is needed. The C:H/I:H/A:H triad reflects that full administrator control over Arcane yields total read/write/delete authority over everything the interface manages.

Business impact concentrates on organizations that expose the Arcane management interface — particularly those that operate a shared or multi-tenant Arcane deployment, or that grant scoped permissions to operators, auditors, or CI/CD service accounts. A single compromised delegated account escalates directly to total control of the Docker estate managed by Arcane, enabling service disruption, data theft from mounted volumes, deployment of malicious images, and lateral movement into workloads. The flaw is not in CISA KEV and no in-the-wild exploitation is documented, but the low complexity and absence of user interaction make it an attractive target once an attacker has any foothold.

Blast radius is bounded by what the Arcane instance controls: every container, image, network, and volume visible to it, plus any credentials or secrets those workloads hold. Because Arcane commonly acts as a central management plane, one successful takeover can cascade across multiple hosts and environments.

Detection Guidance

Sigma Rule

title: Arcane Privilege Escalation - Password Hash Update on Administrator Account
id: 8f6c2a13-4b1e-4d7a-9c33-a1e5f6c9d0b2
status: experimental
description: Detects attempts to change the password hash of an account by a caller lacking matching privilege, or updates targeting the global administrator in Arcane prior to 2.6.0.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-96627
author: Threat Intelligence
date: 2026-01-01
logsource:
  product: arcane
  service: api
detection:
  selection_update_user:
    http.method: 'PUT'
  selection_path:
    http.url|contains: '/users/'
  selection_password_field:
    request.body|contains: 'PasswordHash'
  selection_admin_target:
    request.body|contains|all:
      - 'PasswordHash'
      - 'admin'
  condition: selection_update_user and selection_path and (selection_password_field or selection_admin_target)
falsepositives:
  - Legitimate administrator password rotations performed by a genuine global admin
level: high
tags:
  - attack.t1078
  - attack.t1098
  - cve.2026.96627

YARA Rule

rule CVE_2026_96627_Arcane_UpdateUser_PrivEsc
{
    meta:
        description = "Detects Arcane user update requests attempting to set a password hash for a higher-privileged account"
        cve = "CVE-2026-96627"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-96627"
        severity = "high"
    strings:
        $api = "/api/users/" ascii nocase
        $hash = "PasswordHash" ascii nocase
        $put  = "PUT " ascii
        $admin = "admin" ascii nocase
    condition:
        uint16(0) != 0x4D5A and
        $hash and $api and
        (#put > 0 or $admin)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-96627 Arcane UpdateUser privilege escalation - PasswordHash write to admin account"; flow:established,to_server; http.method; content:"PUT"; http.uri; content:"/users/"; nocase; http.request_body; content:"PasswordHash"; nocase; classtype:attempted-admin; reference:cve,2026-96627; sid:202696627; rev:1;)

Elastic Detection

sequence by user.name, source.ip with maxspan=60s
  [authentication where event.outcome == "success" and event.category == "authentication"]
  [http where http.request.method == "PUT" and
        wildcard(http.request.body, "*PasswordHash*") and
        wildcard(url.path, "*/users/*")]

Splunk SPL Query

index=arcane sourcetype=arcane:http OR sourcetype=arcane:api
  (http_method=PUT OR method=PUT)
  uri_path="*/users/*"
  (request_body="*PasswordHash*" OR body="*PasswordHash*")
| eval target_admin = if(match(lower(coalesce(request_body,body)), "admin"), 1, 0)
| stats count min(_time) as first_seen max(_time) as last_seen
    values(uri_path) as paths values(user) as callers
    by src_ip target_admin
| where count > 0
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="arcane,web,attack,">
  <rule id="2026966" level="10">
    <decoded_as>json</decoded_as>
    <field name="http.method">PUT</field>
    <field name="request.body" type="pcre2">(?i)PasswordHash</field>
    <field name="http.url" type="pcre2">(?i)/users/</field>
    <description>CVE-2026-96627: Arcane UpdateUser password-hash change on user account (possible privilege escalation)</description>
    <mitre>
      <id>T1078</id>
      <id>T1098</id>
    </mitre>
  </rule>
  <rule id="2026967" level="12">
    <if_sid>2026966</if_sid>
    <field name="request.body" type="pcre2">(?i)admin</field>
    <description>CVE-2026-96627: Arcane password-hash change targeting administrator account (critical)</description>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — a single source, the GHSA advisory, claims that version 2.6.0 fixes the issue; this has not been independently confirmed).

1) Immediate mitigations (before/if patching is not possible).

• Audit all Arcane accounts and remove the delegated users:update permission from any identity that does not absolutely require it. This is the primary mitigant, since exploitation requires that permission.
• Enable strong password policies and MFA on the Arcane UI, so that any password-hash substitution is harder to leverage and any account-takeover is easier to detect.
• Restrict network access to the Arcane API and UI (firewall, reverse proxy ACLs, or a VPN/zero-trust gateway) so only trusted administrators and management networks can reach it.
• Enable and forward Arcane application/audit logs to a SIEM; alert on any users update operation involving password-hash fields, especially against the global administrator account.

2) Patch/upgrade.

• Upgrade Arcane to version 2.6.0 or later, which the advisory states fixes the issue. Because the fix is only claimed by a single source, verify the change in the upstream release notes and confirm the version in the running deployment. Where possible, review the diff for the UpdateUser handler to confirm that caller/target privilege comparison is now enforced.

3) Long-term hardening.

• Enforce least privilege for delegated permissions; adopt a policy where only global administrators can modify administrator-class accounts.
• Adopt server-side enforcement of "caller must be equal-or-higher privilege than target" as a general rule across all user-management endpoints, and test it as part of security regression.
• Add authorization tests for user-management handlers in CI, including negative cases where a low-privilege caller attempts to modify a higher-privilege target.
• Rotate the global administrator credentials after any doubt of compromise, and review Arcane and Docker audit logs for suspicious account or container changes.

References

• NVD — CVE-2026-96627: https://nvd.nist.gov/vuln/detail/CVE-2026-96627
• GHSA advisory for Arcane (fix in 2.6.0): referenced as the sole patch source in the provided intelligence
• Arcane project repository / release notes (inspect CHANGELOG for 2.6.0 and the backend/api/handlers/users.go UpdateUser change)
• MITRE ATT&CK — T1078 Valid Accounts: https://attack.mitre.org/techniques/T1078/
• MITRE ATT&CK — T1098 Account Manipulation: https://attack.mitre.org/techniques/T1098/

Threat actor and CISA KEV status: no known threat-actor campaigns are associated with CVE-2026-96627, the issue is not listed in CISA KEV, and no public exploit code or proof-of-concept has been observed at the time of writing.