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

Arcane is an interface for managing Docker containers, images, networks, and volumes. Prior to 2.5.0, UpdateRegistry and TestRegistry in backend/api/services/containerregistryservice.go allow the registry URL to change while preserving the stored encrypted token. When a holder of registries:update and registries:test repoints a generic registry URL without supplying a replacement token, TestRegistry decrypts the preserved token and RegistryLogin sends it to the attacker-controlled host because normalizeRegistryServerAddressInternal does not restrict the destination. This exposes the stored container-registry PAT or password and can enable image access or tampering. This issue is fixed in version 2.5.0.

Arcane versions before 2.0.0 fail to properly restrict template operations, allowing default user role accounts to create, modify, and delete compose templates including instance-wide defaults. Attackers can inject malicious container configurations with privileged settings or host path mounts that execute with administrative privileges when deployed by administrators.

Arcane is an interface for managing Docker containers, images, networks, and volumes. Prior to version 1.13.2, unauthenticated requests could be proxied to remote environment agents, allowing access to remote environment resources without authentication. The environment proxy middleware handled /api/environments/{id}/... requests for remote environments before authentication was enforced. When the environment ID was not local, the middleware proxied the request and attached the manager-held agent token, even if the caller was unauthenticated. This enabled unauthenticated access to remote environment operations (e.g., listing containers, streaming logs, or other agent endpoints). An unauthenticated attacker could access and manipulate remote environment resources via the proxy, potentially leading to data exposure, unauthorized changes, or service disruption. Version 1.13.2 patches the vulnerability.

Summary

Arcane’s updater service supported lifecycle labels com.getarcaneapp.arcane.lifecycle.pre-update and com.getarcaneapp.arcane.lifecycle.post-update that allowed defining a command to run before or after a container update. The label value is passed directly to /bin/sh -c without sanitization or validation.

Because any authenticated user (not limited to administrators) can create projects through the API, an attacker can create a project that specifies one of these lifecycle labels with a malicious command. When an administrator later triggers a container update (either manually or via scheduled update checks), Arcane reads the lifecycle label and executes its value as a shell command inside the container.

If the container is configured with host volume mounts in its Compose definition, the executed command may be able to read from or write to the host filesystem through the mounted paths. This can enable data theft and, in some configurations, escalation to full host compromise (for example, if /var/run/docker.sock is mounted).

Impact

- Remote code execution (RCE) within the updated container context. - Host filesystem access when host volumes are mounted into the container. - Potential data exfiltration via outbound network requests or by exposing readable files. - Potential full host compromise if sensitive mounts are present (e.g., /var/run/docker.sock).

Patches The lifecycle labels com.getarcaneapp.arcane.lifecycle.pre-update and com.getarcaneapp.arcane.lifecycle.post-update have been removed to eliminate this attack surface.