The OpenHands SDK bound its sandbox port to all interfaces by default, handing out root RCE with no authentication
CVE-2026-112346, published on October 26, 2026 and rated CVSS 9.8, shows that the DockerWorkspace and Apptainer launchers in the OpenHands SDK exposed the sandbox server on 0.0.0.0 with authentication disabled by default. Upgrade to version 1.52.0, which confines the port to the loopback, and check that no sandbox is still reachable from the internet.
October 26, 2026. NVD publishes CVE-2026-112346, rated CVSS 9.8, against the OpenHands SDK — one of the most widely used open-source kits for building AI-assisted development agents. October 5, 2026. Version 1.52.0, which fixes the flaw, was already available for download. October 3, 2026. The fix, a simple port-binding change, had already been merged into the main branch. The point that matters: for at least three weeks, anyone running the DockerWorkspace or Apptainer sandbox on a reachable machine was exposing an unauthenticated root shell — and most vulnerability trackers only found out when NVD published it.
The flaw: a port published on every interface, with authentication off by default
OpenHands (formerly OpenDevin) ships a software agent SDK for building autonomous coding agents. To run the agent’s commands safely, the SDK launches a sandbox — most often a Docker container, or Apptainer — plus an agent server that talks to it. That server is what executes the shell commands the agent requests, as root, inside the mounted workspace.
CVE-2026-112346 describes the flaw precisely. The DockerWorkspace and Apptainer launchers published the agent server’s port on 0.0.0.0 — every network interface on the host machine — instead of the loopback. Worse, the session_api_keys list was empty by default, which turned authentication off. In operational terms: anyone who could reach the published port could send unauthenticated HTTP or WebSocket requests, execute arbitrary shell commands as root in the sandbox, access the mounted workspace, and read plaintext secrets from the secrets store.
NVD classifies the flaw as CWE-1327, “binding to an unrestricted IP address” — the same family as database admin interfaces left on 0.0.0.0. The CVSS 3.1 vector is unambiguous: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. No prerequisites, no user interaction, maximum impact on confidentiality, integrity, and availability.
Who is exposed, and who is not
The risk hinges on one variable: the network reach of the published port. On a developer laptop on a local network, behind NAT, exposure is limited to the machine and its immediate neighbors. On a cloud server, a VM with a public address, or a host that publishes ports in a shared cluster, the situation is completely different: the agent server becomes a root entry point reachable from the internet.
The target is all the more attractive to an attacker because the mounted workspace often contains the organization’s source code, and the secrets store exists precisely to hand the agent the API keys, tokens, and credentials it needs to work. A single exposed container therefore combines code execution and secret leakage inside the same perimeter.
The fact that session_api_keys is empty by default makes it worse: a user who installs the SDK and follows the “default” path makes no wrong choice. The vulnerability is shipped by default, which is what makes it silent.
A simple fix, merged before the CVE was published
The fix is instructive in its brevity. PR #5209, opened by Graham Neubig and merged on October 3, 2026, is titled simply “publish Docker ports on loopback”. The change does two things: publish the DockerWorkspace API port (and the optional VS Code port) on 127.0.0.1 on the host side, and propagate the session key to the workspace client. The agent server keeps listening on 0.0.0.0 inside the container, because Docker port forwarding must be able to reach it — but the scope restriction is applied on the host side, at the -p mapping.
Version 1.52.0, released on October 5, 2026, ships the fix with targeted regression coverage. The gap between the fix and CVE-2026-112346, published on October 26, 2026, is the real subject of this article: for three weeks, teams that track their dependencies through NVD or KEV had no signal that a critical flaw had just been fixed in a component they deploy. As of today, CISA has not added it to KEV, and no public exploit is referenced — but the absence of a public PoC does not protect a port left open.
What to do about it
Upgrade the SDK. Any OpenHands installation older than 1.52.0 must be updated immediately if it uses DockerWorkspace or Apptainer. The fix is a version bump, not a complex reconfiguration.
Check the published ports. Look for containers launched with -p 0.0.0.0:…:8000 or a mapping without a host restriction, especially the ghcr.io/openhands/agent-server images. A docker port <container> 8000/tcp that returns anything other than 127.0.0.1 is a red flag.
Rotate the secrets. If a sandbox could have been reached from the internet — for example on an exposed build VM — treat the secrets store and the workspace keys as compromised and rotate them.
Do not let agents expose ports by default. This is the cross-cutting lesson: an agent SDK that publishes a port on every interface without authentication by default is an anti-pattern. Demand loopback binding by default and authentication on by default from your agent tooling.
Verdict
If you deploy OpenHands agents on a reachable machine — a cloud VM, a build server, a cluster node — upgrade to 1.52.0 now and check your port mappings: that is the scenario where an unauthenticated root RCE was genuinely reachable from the internet. If you only use OpenHands locally, behind NAT, the risk is contained, but the upgrade is free and recommended. The lesson that goes beyond OpenHands is that agent SDKs are replaying the database decade’s mistakes in fast-forward: binding on 0.0.0.0, authentication disabled by default, and a silent fix that CVE aggregators only surface three weeks later.