OpenHands flaw opens the agent sandbox to outside commands

What this is about

Anyone running a coding agent in a container expects a separate working environment. A security advisory published on October 26, 2026 shows why that boundary offers limited protection when outsiders can reach the environment's controls. VulnCheck describes a critical vulnerability in the OpenHands Software Agent SDK before version 1.52.0, tracked as CVE-2026-112346.

The potential harm extends beyond the programming assistant itself. According to the advisory, attackers can execute commands inside its sandbox, reach mounted project files and read secrets stored there. They must be able to reach the published container port over the network. This is a configuration issue that operators can investigate, not evidence that every OpenHands installation is publicly vulnerable.

What the OpenHands flaw actually does

The SDK is a toolkit for developers embedding software agents in their own tools. The advisory concerns the DockerWorkspace and Apptainer workspaces. Their launchers bind the agent server to all network interfaces, represented by 0.0.0.0, while an empty list of session keys disables authentication by default.

Under unfavorable network conditions, an internal control channel therefore becomes an open remote control. According to the advisory, reachable HTTP and WebSocket interfaces can accept shell commands without prior authentication. Those commands run with root privileges inside the sandbox. This is explicitly not the same as demonstrated root access to the host, the computer outside the container.

The official release of version 1.52.0 is already dated October 5. It lists a fix that publishes Docker ports only on the local loopback interface. The new development is the October 26 security advisory, not the existence of that update. The advisory identifies versions before 1.52.0 as affected.

Why it matters

Coding agents often receive exactly what an attacker would find valuable: source code, a writable workspace and credentials for development services. These tools are what make the agent useful. Their controls consequently need protection just as much as a conventional administration interface does.

VulnCheck assigns the vulnerability 9.3 out of 10 under CVSS 4.0. The Hacker Wire lists 9.8 under CVSS 3.1, and OpenCVE shows both ratings. The different numbers come from different versions of the scoring system; they do not demonstrate that the vulnerability became more severe between reports. Both classify it as critical.

For operators, the priority is clear: update affected SDK versions, then check the ports, network interfaces and access controls actually exposed by the deployment. A version number alone does not describe the entire setup. Custom proxy rules, port forwarding and different launch parameters also belong in that review. This is a practical recommendation derived from the documented attack path, not a claim about an additional vulnerability.

In plain language

Think of the container as a separate workshop. It holds tools, plans and keys to other work areas. That workshop provides only limited protection to the rest of the building if its remote control hangs unsecured in a public corridor.

A stranger does not need to break through the wall. They can use the intended entrance and make the tools work for them. Fixing the problem therefore means technically restricting access to the workshop, not giving the assistant better instructions about how it should behave.

A practical example

A fictional development team runs three agent containers on a shared test server. Each container has its own project folder; one contains a test credential for an external service. The team discovers that two published ports are reachable from a network that was never intended to control the agents.

First, it restricts that reachability, checks the SDK versions and updates affected installations. It then tests which connections remain possible from both intended and unintended networks. The three containers and two ports are illustrative numbers, not figures from the security report or measurements of a real incident.

If unauthorized access cannot be ruled out, reviewing mounted files and credentials also belongs in the response. Replacing a potentially exposed key addresses a different risk from closing the port. The two actions should be considered separately rather than treating an updated package as proof that earlier exposure no longer matters.

Scope and limits

• Reachability is a prerequisite. The advisory describes an attack through an accessible container port. It does not establish that every local installation can be reached from the internet.
• The sandbox is not the host. The documented impact is root command execution inside the sandbox and access to mounted files and secrets. This does not demonstrate a general container escape.
• No established attack wave. The reviewed entries do not identify a confirmed campaign. However, absence from a known-exploited-vulnerabilities list also does not prove that no abuse has occurred.

SEO & GEO keywords

OpenHands, Software Agent SDK, CVE-2026-112346, coding agents, sandbox security, DockerWorkspace, Apptainer, access control, VulnCheck, developer tools