Exposed OpenHands agent sandboxes: upgrade, then set a session key (CVE-2026-112346)

Home » Alert » Exposed OpenHands agent sandboxes: upgrade, then set a session key (CVE-2026-112346)

ALERT · Patch available. Not known exploited. Last updated 29 October 2026. See the Alert Tracker

If your developers or pipelines run the OpenHands coding agent in Docker or Apptainer sandboxes, check today whether anything other than the host itself can reach those sandboxes. CVE-2026-112346 means that, before version 1.52.0 of the OpenHands Software Agent SDK, anyone who could reach a sandbox’s port could run shell commands in it as root and read the secrets it holds, without a password. Upgrading fixes how Docker publishes the port. It does not turn authentication on, so set a session key as well.

What it is

Side-by-side diagram: Docker after 1.52.0 publishes the agent-server port on 127.0.0.1 only, while Apptainer still binds the agent server to 0.0.0.0 on the host network.
Bind exposure: Docker after 1.52.0 on loopback versus Apptainer still on 0.0.0.0. Credit: Cyber-Threat.net diagram.

OpenHands is an open-source AI coding agent. Its Software Agent SDK runs the agent inside a sandbox: a container with a small web server, the “agent server”, which the agent and the developer’s tools use to run commands, read and write files, and fetch stored secrets. That server is the remote control for the sandbox.

The CVE record (opens in a new tab), published on 26 October by VulnCheck as the CVE Numbering Authority (CNA), says 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.” It goes on: “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.”

Put simply, it is an open door rather than a clever bug. The mounted workspace is usually a real code checkout, and the secrets store is where API keys and tokens for the agent are kept.

Scores

  • CNA (VulnCheck): CVSS 4.0 9.3, Critical (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N), and CVSS 3.1 9.8, Critical. Weakness CWE-1327, binding to an unrestricted IP address.
  • NVD: awaiting analysis when we checked.
  • EPSS: 0.01014 (about 1.0%; 63rd percentile) on the 28 October 2026 score date.

Is it being exploited?

Not as far as anyone has said. CVE-2026-112346 is not in CISA’s Known Exploited Vulnerabilities catalogue (opens in a new tab) (version 2026.10.28), and VulnCheck’s advisory (opens in a new tab) does not report attacks. There is no separate advisory from the OpenHands project. Using it needs no skill, though: anyone who finds an open sandbox can use the server’s own documented API, so treat exposure as the risk.

Who is affected

Rendered diff of OpenHands commit 7b66584 changing DockerWorkspace port publishing from 0.0.0.0 to 127.0.0.1.
DockerWorkspace loopback publish in commit 7b66584. Source: OpenHands, MIT licence (opens in a new tab) (licence (opens in a new tab)).

You are affected if you use the OpenHands Software Agent SDK (the Python packages openhands-sdk, openhands-workspace and openhands-agent-server) before 1.52.0 with the DockerWorkspace or Apptainer launcher, on a machine that other machines can reach. That covers shared development servers, cloud VMs with open security groups, CI runners and research clusters. A laptop on a shared office or café network counts too. The record names only the SDK. It does not say whether the OpenHands web app or OpenHands Cloud are affected, and we have not tested them.

Fixed versions

Table of OpenHands Software Agent SDK versions and what the 1.52.0 fix covers for Docker versus Apptainer, including that authentication stays off by default.
Versions and what the fix covers. Credit: Cyber-Threat.net table from the CVE record and published SDK source.

The record lists 1.52.0 (opens in a new tab) as the fix. It reached PyPI on 5 October, three weeks before the CVE, and the current release is 1.59.0. Four things are worth knowing before you call it done. We read them in OpenHands’ pull requests (opens in a new tab) and source code; OpenHands has not set them out in an advisory.

  • Docker only. The fix (opens in a new tab) makes DockerWorkspace publish the agent server port (and the VS Code port next to it) on 127.0.0.1 only. Inside the container the server still listens on every interface.
  • Authentication is still off by default. The server still accepts requests without a key unless OH_SESSION_API_KEYS_0 (or SESSION_API_KEY) is set. We confirmed this against the official 1.52.0 agent-server build.
  • In fairness. Since July the agent server itself listens only on 127.0.0.1 by default when no session key is set, and warns when told to listen on all interfaces without one (pull request 4180 (opens in a new tab)). Both launchers pass a session key through if you set one. The launchers override the safe default by asking for 0.0.0.0.
  • Apptainer looks unchanged. In our reading of the published code, the Apptainer launcher is identical in 1.51.0, 1.52.0 and 1.59.0 and still starts the server with --host 0.0.0.0 on a host port, and Apptainer containers normally share the host’s network. OpenHands has not confirmed this, and the CVE record lists 1.52.0 as the fix for both launchers. Until it says otherwise, we would not rely on upgrading alone on Apptainer hosts.

How to find it in your estate

Terminal capture of own-lab checks: OpenHands Agent Server 1.51.0 returns HTTP 200 on /api/tools/ without a key; 1.52.0 with a session key returns 401.
Own-lab detection checks on loopback against official 1.51.0 and 1.52.0 agent-server builds. Credit: Cyber-Threat.net lab capture.

Only scan networks you own or are authorised to test. We ran the version and authentication checks below against the official 1.51.0 and 1.52.0 agent-server builds on a loopback address. We have not run the Docker and Apptainer commands in this test.

  • Find the packages. Run pip show openhands-sdk openhands-workspace openhands-agent-server in each environment. Also search lockfiles and requirements files for openhands-. Anything below 1.52.0 is affected.
  • Look at Docker port mappings. Run docker ps --format '{{.Names}} {{.Image}} {{.Ports}}' and look for agent-server images (the default is ghcr.io/openhands/agent-server). A mapping like 0.0.0.0:36957->8000/tcp or [::]:36957->8000/tcp is reachable from other machines. 127.0.0.1:36957->8000/tcp is the fixed default. Existing containers keep their old mappings until they are recreated.
  • Look at listening ports. On Linux, ss -ltnp shows what is listening on 0.0.0.0 or [::]. When no port is set, the SDK picks one at random between 30000 and 39999, and the VS Code port is the next one up. Apptainer sandboxes show up here as the agent server process itself rather than a Docker proxy.
  • Ask the server. From another machine on your network, curl -s http://HOST:PORT/server_info answers without a key and returns JSON containing "title":"OpenHands Agent Server" and the version. Then run curl -s -o /dev/null -w '%{http_code}\n' http://HOST:PORT/api/tools/. A 200 means the server is not asking for a key. A 401 means a key is set. Both requests are read-only.

What to do

Four-step remediation checklist: upgrade and recreate sandboxes, set OH_SESSION_API_KEYS_0, close the network path, and rotate secrets if a sandbox was reachable.
Remediation checklist. Credit: Cyber-Threat.net diagram.
  • Upgrade and recreate. Move the SDK packages to 1.52.0 or later (1.59.0 is current), then stop and recreate running sandboxes so they pick up the new port mapping.
  • Set a session key. Set OH_SESSION_API_KEYS_0 to a long random value in the environment that launches the workspace, and check that /api/tools/ now returns 401 without it. This is the step that actually turns authentication on, on every version and with both launchers.
  • Close the network path. Block inbound connections to the sandbox ports from other machines with a host firewall or security group, especially on Apptainer hosts. If you need remote sandboxes on purpose, put them behind a VPN or an authenticating proxy, never on the open internet.
  • If a sandbox was reachable, assume it was used. Rotate the secrets it held: model provider API keys, Git and cloud tokens, and anything in the secrets store or in the mounted workspace. Review the workspace for changes you did not make before merging anything from it. This is our advice, not vendor guidance.

This is the same lesson as our round-up of four AI agent advisories: an agent’s sandbox is only as safe as whoever can reach its controls. We have not written a Hunt Lab rule for this one, because the problem is exposure, and the checks above find it.

Cyber-Threat.net asked OpenHands to comment on 27 October; it had not responded by our deadline of 09:30 GMT on 29 October. We will update this article if it does.

Sources

Follow Cyber-Threat.net RSSFeedly (opens in a new tab)X (opens in a new tab)Bluesky (opens in a new tab)LinkedIn (opens in a new tab)