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.

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.

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.