Summary
- CVE-2026-112346 affects SDK releases before version 1.52.0.
- An exposed sandbox service may accept unauthenticated HTTP or WebSocket operations.
- The vulnerability record is new, but the corrected release predates its publication.
A critical vulnerability in the OpenHands Software Agent SDK could allow unauthenticated users to execute commands inside AI coding-agent sandbox environments, exposing development files and credentials where affected services are reachable across a network.
The vulnerability, CVE-2026-112346, was formally published on 26 October 2026 and affects SDK releases before version 1.52.0. The corrected release predates the public vulnerability record, so the development is a new disclosure about older software rather than an unpatched weakness in the latest version.
OpenHands provides technology for software agents that can carry out coding tasks, interact with project files and run commands. Its agent SDK supports isolated workspaces intended to limit the consequences of automated execution.
The reported defect concerns DockerWorkspace and Apptainer workspace launchers. Affected versions could start the sandbox service bound to all network interfaces while leaving the configured API-key list empty, disabling the expected authentication check.
Where the service's port was published and reachable, another system could send requests to the agent interface without possessing a valid token. Supported operations could then be invoked outside the normal authenticated client workflow.
The vulnerability description includes arbitrary shell-command execution inside the sandbox, access to mounted workspace contents and potential disclosure of plaintext secrets available within the environment. The severity is rated critical under current vulnerability scoring systems.
A sandbox may contain cloned repositories, test data, environment variables and credentials used for development or automated delivery. The practical consequences therefore depend heavily on what files and permissions the environment exposes.
An isolated sandbox containing only disposable test files presents a different risk from one mounting sensitive internal repositories or holding package-publishing credentials. Network isolation and whether the affected service port is published also determine if another system can exploit the issue.
The finding does not establish that an attacker gains unrestricted root access to the underlying host. The described command execution occurs inside the sandbox, and any movement beyond that boundary would depend on additional mounts, privileges or vulnerabilities.
Nor does the CVE mean that every OpenHands installation was directly accessible from the internet. A service bound to several interfaces can still be protected by host firewalls, container-network rules or separate administrative controls.
The distinction matters for organisations operating shared development machines and continuous integration environments. A coding-agent sandbox may have access to repositories or deployment credentials, even where its users do not have interactive administrative access to other infrastructure.
The problem differs from prompt injection. In a prompt-injection attack, malicious content attempts to redirect the instructions a model follows. Here, the vulnerability concerns unauthenticated access to a conventional network service that supports the coding agent.
An attacker reaching that interface does not need to persuade the model to interpret hostile instructions if the execution service itself accepts unauthorised requests. The risk arises from access-control and deployment configuration rather than language-model reasoning.
The relevant security fix appears in OpenHands Software Agent SDK version 1.52.0. The associated development history describes the change to authentication handling and references the code introduced to correct the vulnerable launch behaviour.
Assessing exposure requires checking the installed version, the launcher in use, the network visibility of the service and the resources mounted into the workspace. Changing only the agent's prompt or task instructions does not directly correct the underlying server-access weakness.
The correction concerns the network service that supports the agent, so administrators must distinguish the host's access-control settings from the permissions granted to the model inside the workspace. A prompt that discourages dangerous operations is not a substitute for service authentication, and a network firewall can materially change whether the vulnerable endpoint is reachable.
The public advisory does not establish confirmed exploitation of customer systems or the number of vulnerable deployments still in operation. It identifies a clear affected-version boundary and a serious potential attack against reachable services used to support automated software development.
