The coding agent needs a command executor within its workspace, but the same server interface becomes a remote-control surface when its host binds 0.0.0.0 and accepts empty session keys. The disclosed issue concerns users who exposed the container or sandbox agent-server port: another network principal could run commands with the agent-server permissions…
Inspect the ClaimsCase · DiggingBeagle record
OpenHands sandbox server accepted unauthenticated remote commands on exposed ports
An SDK agent server accepted sessions without configured API keys when a host mapped its sandbox service broadly; a loopback binding and API-key change shipped in version 1.52.0. The demonstrated authority was inside the sandbox.
Scope
No host-VM escape or verified production victim follows from the report. Docker and Apptainer deployments have different port topologies, and a server listening internally is not automatically reachable from the public internet.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- not established
- Evidence
- Grade B
- Remediation
- patch available
- AI role
- AGAINST AI
Basis and provenance
Enrich update: CLM-ENRICH-20261027-24 cites SRC-2026-CP21-OPENHANDS-AGENT-SERVER-EXPOSED at OpenHands PR 5209, Why, Summary and session API key forwarding. New evidence concerns the bounded reported mechanism, prerequisite or outcome; setting research_demonstration; exploit status not_established; remediation status patch_available. No independently comparable impact scale, affected production population or universal exploit success measure was established, so the impact band remains null. Original Claims remain individually attributable and any observed incident or simulated result is distinguished in the narrative.
Assessed Oct 27, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-ENRICH-20261027-24 · OpenHands agent-server SDK PR 5209: restrict binding and session keys
At a glance
The case illustrates how a normally deliberate AI execution surface crosses into a network vulnerability when its control plane is published without caller identity.
Read the implicationsNo host-VM escape or verified production victim follows from the report. Docker and Apptainer deployments have different port topologies, and a server listening internally is not automatically reachable from the public internet.
Limits and uncertaintyFull account
The coding agent needs a command executor within its workspace, but the same server interface becomes a remote-control surface when its host binds 0.0.0.0 and accepts empty session keys. The disclosed issue concerns users who exposed the container or sandbox agent-server port: another network principal could run commands with the agent-server permissions and reach workspace material.
The OpenHands SDK patch changes agent-server host exposure and session authentication so an externally reachable control endpoint no longer accepts unauthenticated execution by default. The mitigation is associated with SDK 1.52.0. No host-VM escape or verified production victim follows from the report. Docker and Apptainer deployments have different port topologies, and a server listening internally is not automatically reachable from the public internet.
Upgrade to SDK 1.52.0 and test exposed port bindings plus actual authentication failure for unauthorized clients. Host firewall isolation is additional defense but not a substitute for service authentication. The case illustrates how a normally deliberate AI execution surface crosses into a network vulnerability when its control plane is published without caller identity. Primary evidence.
Additional evidence and trust boundary
The published fix addresses two different controls. Binding Docker-exposed ports to host loopback reduces who can reach the agent server; propagating a session API key ensures an authorized SDK client can authenticate consistently to its HTTP and WebSocket endpoints. Neither control implies a VM hypervisor escape was demonstrated. Operators must also verify that reverse proxies, firewall rules and alternative workspace backends do not re-expose the service. Supporting record.
Mechanism and trust boundary
- 01
Step
- 02
Step
- 03
Step
Timeline
- Oct 26, 2026disclosure
Public disclosure
Claims & evidence
CLM-ENRICH-20261027-24OpenHands patch PR 5209 notes that its SDK client already connects through 127.0.0.1 while Docker had been publishing the agent API and optional VS Code ports on every host interface; the change confines those host mappings to loopback.supported
Basis: reported finding
- supportsOpenHands agent-server SDK PR 5209: restrict binding and session keysprimary disclosure
OpenHands PR 5209, Why, Summary and session API key forwarding
CLM-CP21-OPENHANDS-AGENT-SERVER-EXPOSED-1The OpenHands SDK patch changes agent-server host exposure and session authentication so an externally reachable control endpoint no longer accepts unauthenticated execution by default. The mitigation is associated with SDK 1.52.0.supported
Basis: reported finding
- supportsOpenHands agent-server SDK PR 5209: restrict binding and session keysprimary disclosure
PR 5209 description, changed host binding and session_api_keys, tests
Implications
The case illustrates how a normally deliberate AI execution surface crosses into a network vulnerability when its control plane is published without caller identity.
Controls and mitigations
- Upgrade to SDK 1.52.0 and test exposed port bindings plus actual authentication failure for unauthorized clients. Host firewall isolation is additional defense but not a substitute for service authentication.
Unknowns and contradictions
- No host-VM escape or verified production victim follows from the report. Docker and Apptainer deployments have different port topologies, and a server listening internally is not automatically reachable from the public internet.
Sources and citation
Material revision history
- Oct 27, 2026 · Canonical change recorded · new in release · revision 196