CVE-2026-112346 in Software Agent SDK
Summary
by MITRE • 10/26/2026
OpenHands Software Agent SDK before 1.52.0 contains an unauthenticated remote code execution vulnerability where 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. Attackers who can reach the published container port can send unauthenticated HTTP and WebSocket requests to execute arbitrary shell commands as root in the sandbox, access the mounted workspace, and read plaintext secrets from the secrets store.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The OpenHands Software Agent SDK prior to version 1.52.0 contains a critical security misconfiguration that results in unauthenticated remote code execution within its containerized environment. This vulnerability stems from the default behavior of both DockerWorkspace and Apptainer workspace launchers, which bind the sandbox agent server interface to all network addresses, specifically 0.0.0.0, rather than restricting access to localhost or a specific internal subnet. Concurrently, these launchers initialize with an empty session_api_keys list, effectively disabling authentication mechanisms for incoming requests by default. This combination creates a scenario where any entity capable of reaching the published container port can interact directly with the agent server without providing valid credentials.
From a technical perspective, this flaw represents a severe failure in secure defaults and access control implementation. By exposing the management interface to all network interfaces and omitting mandatory authentication checks, the system allows unauthenticated HTTP and WebSocket requests to be processed by the backend logic responsible for executing commands within the sandbox environment. Since the agent typically operates with elevated privileges to facilitate software development tasks, these unauthorized requests can execute arbitrary shell commands as the root user inside the containerized workspace. This level of access bypasses standard security boundaries intended to isolate the agent's operations from external threats or untrusted inputs.
The operational impact of this vulnerability is significant and multifaceted. An attacker who gains network reachability to the exposed port can achieve full control over the sandbox environment, including executing arbitrary code with root privileges. Beyond command execution, the lack of authentication allows attackers to access the mounted workspace directory structure, potentially leading to data exfiltration or tampering with source code and configuration files stored within that volume. Furthermore, because many development workflows involve injecting sensitive information such as API keys, database passwords, or cloud credentials into the environment via a secrets store, this vulnerability enables direct reading of plaintext secrets. This compromises not only the integrity of the specific project but also potentially affects other systems where those leaked credentials are reused.
This issue aligns with CWE-287, which describes Improper Authentication, as well as CWE-436, Interpretation Error, in the context of how configuration defaults were handled without adequate security constraints. In terms of the MITRE ATT&CK framework, this vulnerability facilitates Initial Access through unauthenticated network services and allows for Execution via arbitrary command execution within a containerized environment. It also supports Lateral Movement if the compromised sandbox is used as a pivot point to attack other systems on the same network segment due to the broad binding address.
To mitigate this risk, organizations must immediately upgrade OpenHands Software Agent SDK to version 1.52.0 or later, where these default configurations have been corrected to enforce authentication and restrict network bindings appropriately. For environments that cannot be upgraded instantly, administrators should implement strict firewall rules to ensure that the container port is not exposed to untrusted networks, restricting access solely to localhost or authorized internal subnets. Additionally, verifying that session_api_keys are properly configured in deployment manifests before launching workspaces can provide a layer of defense-in-depth, although upgrading remains the primary and most effective remediation strategy.