OpenHands agent SDK left Docker sandboxes open to the network without a password (CVE-2026-112346)

Update, November 5, 2026: There is still no report of exploitation: CISA's assessment, added to the CVE record on November 4, lists exploitation as "none" (and the flaw as automatable). The current SDK release on PyPI is 1.60.1. In our reading of that release's source package, the Apptainer launcher still starts the agent server on all interfaces (0.0.0.0) and relies on a SESSION_API_KEY environment variable for authentication, so Apptainer users should set one (see checklist).

OpenHands Software Agent SDK, the toolkit behind the OpenHands CLI and OpenHands Cloud, had a flaw that left its Docker and Apptainer sandboxes reachable over the network with authentication switched off by default. Anyone who could reach the sandbox's published port could run commands as root inside it and read the agent's workspace and stored secrets. The fix shipped in version 1.52.0 on October 5, 2026; the CVE was published on October 26, 2026. Teams that build agents on the SDK should check their version and rotate secrets if a sandbox may have been exposed.

What happened, in plain English

OpenHands is an open-source AI coding agent. You give it a task, and it reads code, runs terminal commands and edits files to complete it. The OpenHands Software Agent SDK (software development kit) is the set of building blocks developers use to make their own agents of this kind; according to its GitHub page, it is also the engine behind the OpenHands command-line tool and OpenHands Cloud.

Because an agent runs real commands, people usually put it in a sandbox: a Docker container (a lightweight, sealed-off mini-computer) or an Apptainer container (a similar technology common on research clusters). Inside the sandbox, a small "agent server" takes instructions from the SDK and carries them out.

The problem, published as CVE-2026-112346 (CVE is the public catalogue of known vulnerabilities), was in how the SDK started those sandboxes. The agent server's port was published on every network interface of the host machine, not only on the machine itself. And unless the developer had set a session API key (a password for the agent server), authentication was off.

Think of a workshop with a robot that does whatever it is told. The robot was meant to take orders only from the person in the room. Instead, its intercom was wired to the street, and it did not ask who was speaking.

Anyone who could reach that port, for example on the same office network, Wi‑Fi or cloud network, could tell the agent server to run commands as root (the all-powerful administrator account) inside the sandbox, open the project files mounted into it, and read the secrets the agent had been given, such as API keys, in plain text.

Are you affected? What to do now

Most readers have nothing to do. This affects developers and teams who build or run agents directly with the OpenHands Software Agent SDK and use its Docker or Apptainer workspace launchers. The advisory names the SDK, not the OpenHands web app; whether a particular OpenHands app or CLI release bundled an affected SDK version is not stated in the advisory.

Affected: OpenHands Software Agent SDK, all versions before 1.52.0, using the DockerWorkspace or Apptainer workspace launchers with no session API key set. Fixed: 1.52.0, released October 5, 2026. The newest release of the openhands-sdk and openhands-workspace packages on PyPI as of November 5, 2026 is 1.60.1.

Checklist:

• Find out if you use the SDK. In the project's Python environment, run pip show openhands-sdk openhands-workspace (or check your lock file) and note the version.
• Upgrade to 1.52.0 or later — preferably the current release — across all OpenHands SDK packages in the environment.
• Check what was exposed. On machines that ran sandboxes, list running containers and their published ports (docker ps). A published port shown as 0.0.0.0: or [::]: was reachable from the network; after the fix it should show 127.0.0.1:.
• Assume exposure if the host was reachable. If an affected version ran on a shared, office, lab or cloud machine without a firewall restricting those ports, treat secrets given to the agent as possibly read: rotate model-provider API keys, Git tokens and cloud credentials.
• Set a session API key for the agent server even after upgrading, so a mistake in network configuration does not leave the server open. If you use the Apptainer launcher, set the SESSION_API_KEY environment variable before starting the workspace: in the current release the server still listens on all interfaces.
• Restrict ports at the firewall or security group on hosts that run agent sandboxes, as a second layer.

No indicators of compromise (IOCs) have been published, and neither the advisory nor CISA reports exploitation.

The expert view

The root cause is a classic one: an insecure default in a component nobody thinks of as a network service. VulnCheck classifies it as CWE-1327, binding to an unrestricted IP address. Two settings combined. The workspace launchers published the container's API port on all host interfaces, and the agent server treated an empty session_api_keys list as "no authentication required". Either alone would be survivable. Together, an internal control channel became an unauthenticated remote command endpoint.

The fix (pull request #5209, "publish Docker ports on loopback") is telling. The SDK client already connected to 127.0.0.1, so exposing the port externally was never needed. The patch publishes the API port, and the optional VS Code port, on loopback only; the server still listens on all interfaces inside the container so Docker's forwarding works. The same change makes the client send a configured session key on both HTTP and WebSocket requests. Release notes for 1.52.0 list it as an ordinary bug fix, not a security fix; the CVE followed three weeks later.

Why does it matter more than a typical open port? An agent sandbox is a concentration point. It holds a working copy of source code, a terminal, and the credentials the agent needs to push code, call models or reach cloud services. Root inside the container is not root on the host, but it is everything the agent could do, which is often a lot.

Severity: VulnCheck scores it 9.3 (CVSS 4.0); CVSS 3.1 trackers show 9.8. Those scores assume network reachability. On a laptop behind a home router the practical risk is low; on a cloud VM with a permissive security group, or a shared lab network, it is as serious as the number says. The score is fair for the exposed case and overstated for the isolated one.

This fits a pattern we have covered repeatedly in 2026: AI agent infrastructure — MCP servers, inference servers, agent runtimes — shipping control interfaces that are unauthenticated by default and assume a trusted network.

Still unknown: whether any exposed instances were found or abused, and which OpenHands app or CLI releases bundled affected SDK versions. The advisory says both the Docker and Apptainer launchers were affected, but the fix pull request describes the Docker workspace only, and the Apptainer launcher in the current release still binds the server to all interfaces; neither OpenHands nor VulnCheck has said whether Apptainer received a separate fix.

Official sources

• VulnCheck advisory, CVE-2026-112346: https://www.vulncheck.com/advisories/openhands-software-agent-sdk-unauthenticated-sandbox-agent-server-rce
• CVE record: https://www.cve.org/CVERecord?id=CVE-2026-112346
• Fix pull request #5209: https://github.com/OpenHands/software-agent-sdk/pull/5209
• Fix commit: https://github.com/OpenHands/software-agent-sdk/commit/7b66584ff8899144eb4ce679c2811861342af9de
• Release v1.52.0: https://github.com/OpenHands/software-agent-sdk/releases/tag/v1.52.0
• OpenHands Software Agent SDK repository: https://github.com/OpenHands/software-agent-sdk
• openhands-workspace on PyPI: https://pypi.org/project/openhands-workspace/
• Coverage: Strix CVE entry: https://www.strix.ai/cve/CVE-2026-112346
• Coverage: CVE Brief, October 27, 2026: https://cvebrief.com/archive/2026/10/27/