At-a-glance summary

• CVE ID: CVE-2026-23520
• Affected product: Arcane Docker Manager
• Vulnerability type: OS command injection
• CVSS v3.1 score: 9.0 (Critical)
• Severity: Critical
• Attack vector: Network
• Privileges required: Low (authenticated user)
• User interaction: Required (admin or scheduled updater)
• Exploitability: High in real environments
• Exploit availability: No widely published public exploit; conceptually trivial to weaponize (educational/lab use only)
• Patch status: Fixed in Arcane v1.13.0

What this vulnerability is

Arcane Docker Manager includes an automated updater feature that can run commands before and after container updates. These commands are defined using special Docker labels:

• com.getarcaneapp.arcane.lifecycle.pre-update
• com.getarcaneapp.arcane.lifecycle.post-update

The idea behind these labels is convenience: let administrators run cleanup tasks, migrations, or health checks when a container is updated.

The problem is how Arcane executes these labels.

Instead of treating label values as controlled scripts or validated commands, Arcane passes the label content directly into a shell using /bin/sh -c. There is no sanitization, no escaping, and no allow-list of permitted commands.

At the same time, Arcane allows any authenticated user (not just admins) to create projects via its API and define these lifecycle labels.

This combination creates a dangerous situation:

• A low-privileged user can store a malicious shell command inside a project label.
• That command does nothing immediately, so it may go unnoticed.
• Later, when an administrator triggers an update or when the automatic updater runs, Arcane executes the label.
• The malicious command runs with the permissions of the container update process.

This is a classic stored command injection problem with delayed execution.

Why this is especially dangerous

This vulnerability is not just about running a command in a container. In real-world setups, containers often have:

• Mounted host volumes
• Access to Docker sockets
• Elevated Linux capabilities
• Network access to internal services
• Secrets injected via environment variables

If a malicious command executes in such an environment, the attacker may be able to:

• Read sensitive configuration files or secrets
• Modify container images or application code
• Pivot to other containers
• Interact with the Docker daemon
• Achieve persistence
• In worst cases, escape to the host

Even if the container itself is well isolated, the attacker gains reliable remote code execution inside managed infrastructure.

How exploitation would realistically happen

This is a conceptual explanation for defensive understanding only.

1. An attacker gains access to any valid Arcane account (phishing, reused password, insider threat, or weak access control).
2. The attacker creates a new project or modifies an existing one and sets a lifecycle label containing shell syntax.
3. Nothing happens immediately, which helps the attack stay hidden.
4. At a later time, an admin performs a routine update or the scheduled updater runs automatically.
5. Arcane executes the label using /bin/sh -c.
6. The attacker’s command runs inside the container environment.

This delayed execution model makes detection harder and increases the likelihood of success.

Exploit and PoC status (educational context)

As of now, there is no widely distributed public exploit or turnkey PoC. However, this should not be seen as reassuring.

From a technical standpoint, this vulnerability is extremely easy to weaponize for anyone with basic shell knowledge and access to an Arcane instance. Because of that, defenders should assume that:

• Targeted exploitation is plausible
• Insider abuse is possible
• Once the issue becomes well-known, public exploits may appear quickly

MITRE and weakness classification

• CWE-78: Improper Neutralization of Special Elements used in an OS Command
• MITRE ATT&CK techniques involved:
  • T1059 – Command and Scripting Interpreter
  • T1078 – Valid Accounts
• Primary tactics:
  • Initial Access (via legitimate credentials)
  • Execution (via shell command injection)

How defenders can detect exploitation attempts

Detection works best when you combine application logs, runtime behavior, and correlation.

Key log sources to monitor

1. Arcane application and audit logs
   • Project creation and modification events
   • Lifecycle label changes
   • User identity and timestamps
2. API and reverse proxy logs
   • POST/PUT requests to project endpoints
   • Request bodies containing lifecycle label names
3. Container runtime logs
   • Docker update and exec events
   • Unexpected process execution during updates
4. Host process and audit logs
   • /bin/sh or sh -c spawned by Arcane or container runtimes
   • Parent processes tied to update workflows
5. Network and egress logs
   • New or unusual outbound connections from containers after updates

What to look for

• Lifecycle labels appearing in projects created by non-admin users
• Label values containing shell metacharacters or control operators such as:
  • ;
  • &&
  • ||
  • backticks
  • $()
  • redirections (>, 2>&1)
  • embedded newlines
• A short time gap between:
  • Project creation or modification
  • Container update execution
  • New processes or network activity
• Containers that behave differently only after an update cycle

Sigma rules

1. Detect lifecycle label usage

title: Arcane Project Uses Lifecycle Labels
id: arcane-lifecycle-label-detection
status: experimental
description: Detect creation or update of Arcane projects that define lifecycle labels.
logsource:
  product: webserver
  service: arcane-api
detection:
  selection:
    http.request.method:
      - POST
      - PUT
    http.request.body|contains:
      - "com.getarcaneapp.arcane.lifecycle.pre-update"
      - "com.getarcaneapp.arcane.lifecycle.post-update"
  condition: selection
level: high

2. Detect suspicious shell characters in labels

title: Arcane Lifecycle Label Contains Shell Operators
id: arcane-lifecycle-shell-operators
status: experimental
description: Flags lifecycle labels that contain shell control characters.
logsource:
  product: arcane
  service: application
detection:
  selection:
    message|contains:
      - "com.getarcaneapp.arcane.lifecycle"
  keywords:
    - ";"
    - "&&"
    - "||"
    - "`"
    - "$("
    - "\n"
  condition: selection and any of keywords
level: critical

3. Detect shell execution during updates

title: Shell Spawned During Arcane Update
id: arcane-shell-spawn-update
status: experimental
description: Detect /bin/sh executions linked to Arcane update workflows.
logsource:
  product: linux
  service: auditd
detection:
  selection:
    process.name: sh
    process.args|contains: "-c"
    parent.process.name|contains:
      - "arcane"
      - "docker"
      - "containerd"
  condition: selection
level: critical

How to harden Docker environments to reduce impact

Even after patching, runtime hardening is critical:

• Run containers as non-root users
• Drop all Linux capabilities by default and add only what is required
• Avoid mounting sensitive host paths into containers
• Never expose /var/run/docker.sock unless absolutely necessary
• Use seccomp and AppArmor/SELinux profiles
• Prefer read-only filesystems with explicit writable volumes
• Segment management tooling on separate networks
• Monitor container process creation and outbound connections
• Treat container updates as a security-sensitive event

These steps dramatically reduce the blast radius if a command ever executes unexpectedly.

What you should do now

1. Upgrade Arcane immediately to v1.13.0 using the official release:
   https://github.com/getarcaneapp/arcane/releases/tag/v1.13.0
2. Temporarily restrict who can create or modify projects until the upgrade is complete.
3. Deploy detection rules and review historical logs.
4. Investigate any lifecycle labels that already exist.
5. Harden container runtimes to limit post-exploitation impact.
6. Rotate secrets if you suspect any unauthorized execution.

Final takeaway

This vulnerability is dangerous not because it is complex, but because it is simple, quiet, and executed later by trusted processes. Those traits make it ideal for real-world abuse. Treat it with urgency, patch promptly, and use detection to ensure it was not exploited before remediation.