OpenHands SDK Flaw Left Agent Sandboxes Answering Anyone on the Network

A sandbox is only as private as the ports it publishes. For OpenHands developers who built on the project’s Software Agent SDK, the default setup published the agent’s command server to the whole network and then left the password field empty. The flaw now has an identifier, CVE-2026-112346, which entered the National Vulnerability Database on October 26, 2026 and was mirrored into GitHub’s advisory database as GHSA-rp7h-crm7-h5qj the same day. It carries a CVSS 3.1 base score of 9.8, the “critical” band. VulnCheck’s advisory for the same CVE scores it 9.3 under CVSS 4.0 and credits a researcher using the handle mil4n.

The advisory covers every SDK release before 1.52.0. That version shipped on October 5, so teams that update regularly are already protected. The new CVE matters for everyone else, because vulnerability scanners and dependency bots usually act on a CVE, not on a quietly worded changelog line.

How a local helper became a network service

OpenHands is an open-source platform for software agents, and its SDK lets developers start an agent inside a container that holds a full workspace. The agent server inside that container accepts HTTP and WebSocket requests. Those requests can run shell commands, read and write files in the mounted project, and use the secrets store that holds API keys for the agent’s tools.

According to the advisory, the DockerWorkspace and Apptainer workspace launchers “bind the sandbox agent server to all network interfaces (0.0.0.0) with an empty session_api_keys list, disabling authentication by default.” Anyone who could reach the published port could therefore “execute arbitrary shell commands as root in the sandbox, access the mounted workspace, and read plaintext secrets from the secrets store.”

The project’s own issue tracker shows how the gap arose. Issue #5379, opened on September 29 and filed by an OpenHands agent on behalf of maintainer Graham Neubig, notes that the workspace client always connects through 127.0.0.1. Docker, however, was publishing the API port, plus a VS Code port when extra ports were enabled, on every host interface. The client also hard-coded its API key to None, so a session key forwarded into the container was never used. The design was meant for one machine, but on a laptop joined to shared Wi-Fi, a cloud VM with a permissive security group, or a CI runner on a flat network, it behaved like a public service.

What changed in 1.52.0

The fix landed as pull request #5209, merged on October 3, and shipped in 1.52.0 two days later. Its changelog entry is a single line: “publish Docker ports on loopback.” In practice, the launcher now passes -p 127.0.0.1:<port>:8000 to Docker, so the server still listens inside the container while the host exposes it only to itself. The same change makes the client read the configured session key, preferring the newer OH_SESSION_API_KEYS_0 variable over the older SESSION_API_KEY.

The SDK has moved on quickly since then. Version 1.58.2 was published on October 25, so even fairly conservative pins are probably past the vulnerable range.

The Apptainer caveat

The fix and the advisory don’t line up perfectly. The CVE names the Apptainer launcher alongside Docker, but the triage notes on issue #5379 list “no change to ApptainerWorkspace” as an explicit non-goal. In the current main branch, the Apptainer launcher still starts the server with --host 0.0.0.0. Apptainer containers normally share the host’s network, so that address applies to the host itself. The launcher sets its client key from the SESSION_API_KEY environment variable when one is present, and the field description says key variables are forwarded so the server “can authenticate network-bound requests when it binds 0.0.0.0.”

In other words, on HPC clusters and other Apptainer setups, protection depends on whether a session key is actually configured, not just on the version number. Writeble has not tested either launcher.

What to do

• Upgrade openhands-sdk and openhands-workspace to 1.52.0 or later. The current release line is 1.58.x.
• Set a session API key explicitly, preferably through OH_SESSION_API_KEYS_0, especially on Apptainer.
• Check hosts that ran older SDK versions for exposed ports in the agent-server range, and rotate any credentials that sat in the workspace secrets store while those ports were reachable.
• Don’t rely on a sandbox’s root user being harmless. The mounted project directory and forwarded secrets were exactly what the open port gave away.

The episode fits a pattern that keeps recurring in agent tooling. Components built as local conveniences, such as an inspector, a dev server or a sandbox controller, accept commands by design. The only real defense is to make sure the network can’t reach them. GitHub still lists the advisory as unreviewed, and no exploitation has been reported publicly. With a 9.8 score now attached, though, older pinned deployments are likely to be scanned for.