How to Check OpenHands Docker Port Exposure and Fix It

# docker# ai# cve
How to Check OpenHands Docker Port Exposure and Fix Itorca forge

Using OpenHands CVE-2026-112346 as an example, this guide shows how to check Docker’s published ports and restrict them to loopback. It also covers checking the version and session API key, plus precautions when using Apptainer.

📝 Originally published (in Japanese) at forge.workstyle.tech.

TL;DR: Docker port publishing without a host IP can expose a port on all host interfaces. CVE-2026-112346 could allow unauthenticated remote code execution in the sandbox when that port is reachable. Check the installed version, bind the host port to 127.0.0.1, and configure the session API key.

1. Check the Installed Version

First, check the versions of the related packages.

pip show openhands-sdk openhands-workspace
Enter fullscreen mode Exit fullscreen mode

According to the CVE description, versions of the OpenHands Software Agent SDK earlier than 1.52.0 are affected. The fix was released in version 1.52.0. If you’re using a version earlier than 1.52.0, update it. NVD v1.52.0 release

To update the packages, update at least the following packages according to the procedures for your environment.

pip install --upgrade openhands-sdk openhands-workspace
Enter fullscreen mode Exit fullscreen mode

If your environment uses dependencies or a lockfile, update them using your usual process, then run pip show again to confirm the installed versions.

2. Check Docker’s Published Ports

Next, list the running containers:

docker ps
Enter fullscreen mode Exit fullscreen mode

Check the PORTS column in the output. For example, an entry like this means the port is published on all host interfaces:

0.0.0.0:36957->8000/tcp
Enter fullscreen mode Exit fullscreen mode

If it starts with 127.0.0.1, the port is published only on the host’s loopback interface:

127.0.0.1:36957->8000/tcp
Enter fullscreen mode Exit fullscreen mode

You can also check an individual port with this command. Replace <コンテナ> (container) with the name or ID of the container you want to inspect.

docker port <コンテナ> 8000/tcp
Enter fullscreen mode Exit fullscreen mode

If the output starts with 127.0.0.1:..., it’s bound to loopback. If the host-side address is something like 0.0.0.0, check the scope of the published port. In the verification results for the fix PR, this command output was 127.0.0.1:36957. PR #5209

3. Bind the Published Port to Loopback

When you specify docker run yourself, -p <host-port>:<container-port> publishes the port on all interfaces if you omit the host IP address. To bind it only to the host’s loopback interface, specify 127.0.0.1 as the host IP. PR #5209

docker run -p 127.0.0.1:<host-port>:<container-port> ...
Enter fullscreen mode Exit fullscreen mode

After updating the startup configuration this way, restart the container and check the PORTS column in docker ps and the output of docker port again. Confirm that the output starts with 127.0.0.1.

In the OpenHands fix, the server inside the container still uses --host 0.0.0.0. The loopback restriction belongs in the host-side port publishing configuration, not inside the container. The PR description explains that the server must listen on 0.0.0.0 inside the container so Docker’s bridge forwarding can reach it. PR #5209

4. Set the Session API Key

The CVE description says authentication was disabled by default when session_api_keys was empty. Set a session API key according to your environment’s configuration, and make sure both the client and server use the same key. NVD

The DockerWorkspace fix changed the client to check OH_SESSION_API_KEYS_0 first and fall back to SESSION_API_KEY, matching the server’s precedence. Check the actual setting name and how to pass it based on your startup configuration. PR #5209

Make sure to check both that the port is bound to loopback and that an API key is set. The former limits exposure on the host side; the latter is relevant to session API authentication.

Why an Agent Sandbox Can Cause Greater Damage

An agent sandbox is a place where AI can run shell commands and read and write files. It is designed to let the agent do anything it needs inside, so if someone on the outside can reach it without authentication, that same “anything” is handed directly to them. The CVE description lists what an attacker could do: run commands as root, access the mounted workspace, and read plaintext secrets from their storage location. NVD

The workspace will often contain the repository you’re working on, and the secrets may include LLM API keys. The sandbox protects the host; it does not protect what’s inside the sandbox.

If You Use Apptainer

The CVE description says Apptainer workspaces are also affected. However, the Docker fix PR targets DockerWorkspace and explicitly states that other workspace types, such as ApptainerWorkspace, are not changed. NVD issue #5379

If you use Apptainer, set a session API key and make sure the port is not reachable from outside. Don’t infer Apptainer’s status from the Docker fix alone; check your own launch configuration and which networks expose the port.

Key takeaways

  • Check openhands-sdk and openhands-workspace; update versions earlier than 1.52.0.
  • Inspect docker ps and docker port for host port bindings.
  • Bind the host side to 127.0.0.1 and verify the mapping after restarting the container.
  • Configure the same session API key on the client and server.
  • For Apptainer, inspect the actual launch settings and network exposure; the DockerWorkspace fix does not establish its state.

Related Articles