OpenHands local runtime defaults and API keys create two different exposure questions
OpenHands local runtime defaults and API keys create two different exposure questions
OpenHands combines a web application with an agent server and a workspace where coding tasks run. The local quick-start documentation shows the application at a localhost port, while the agent server architecture page says the server starts without API authentication by default. Those are related defaults, but they answer different questions: who can reach the user interface, and who can call the underlying runtime API.
On 2026-11-05, a count-only ZoomEye query with sub_type=all, page 1 and page size 1 returned 857 matches for title="OpenHands" and zero for app="OpenHands". The title observation is broad and may include documentation, repositories and non-running deployments. The zero application count does not mean there are no exposed deployments. It means the chosen application fingerprint did not match in this observation.
The runtime boundary is the important one
The OpenHands architecture documentation notes that the agent server can be configured with session API keys and that sensitive values stored with conversations are encrypted by OH_SECRET_KEY. It also lists API routes and an OpenAPI documentation endpoint. A server with no API authentication is appropriate only when it is isolated to a trusted host or process boundary. A public network path changes that assumption.
The web application may hold model-provider keys, a workspace with source code and conversation history. The agent server can execute commands and manipulate files inside its workspace. A user who can reach that runtime without authentication may be able to start work, read session data or alter settings depending on the deployment. This article does not claim a specific exploit against an OpenHands version; it highlights the default-to-exposure review.
Test each listener separately
From outside the management network, test the UI port, the agent server port and the OpenAPI documentation path. A proxy that authenticates the UI does not necessarily protect a runtime port bound on another interface. Confirm the bind address, container port mapping, firewall rule and proxy route. If session API keys are configured, verify that a request without the expected header is rejected and that keys are not placed in browser-visible configuration.
Set a stable OH_SECRET_KEY and protect it like any other application secret. Rotate provider API keys separately from the application secret. Limit the workspace's access to the host filesystem and outbound network. Review Docker socket mounts and host mounts because an agent that can control containers or read broad host paths has authority far beyond editing repository files.
Interpret the title count carefully
The 857 title matches are useful for finding documentation and public references, not for proving that 857 OpenHands runtimes are reachable. The title field is a visible label and can appear in tutorials, issue pages and marketing content. A zero app count is also not a negative proof. ZoomEye fingerprints are a measurement aid, not a complete census.
For owned deployments, build an inventory from process listeners, container mappings and reverse-proxy routes rather than relying on external search. Record the version, image digest, public hostname, authentication mode, session key source and workspace mount. Compare that inventory with the title matches that resolve to your domains.
Incident response
If a runtime was exposed, preserve its configuration, session keys, workspace contents and command history according to policy. Determine whether an unauthorised actor could start conversations, read stored provider credentials or alter the model endpoint. Rotate provider keys and session API keys, revoke active conversations where supported, and rebuild the runtime from a clean workspace.
OpenHands makes agent execution visible and controllable. The security review must make the listener boundary equally visible, because a localhost default is safe only until a deployment changes the bind or publishes it through an unprotected proxy.
References
- OpenHands local setup
- OpenHands agent server architecture
- ZoomEye title="OpenHands" count observation
Mentions
OpenHands local runtime defaults and API keys create two different exposure questions OpenHands local runtime defaults and API keys create two different exposure questions OpenHands combines a web application with an agent server and a workspace where coding tasks run. The local quick-start documentation shows the application at a localhost port, while the agent server architecture page says the server starts without API authentication by default. Those are related defaults, but they answer different questions: who can reach the user interface, and who can call the underlying runtime API. On 2026-11-05, a count-only ZoomEye query with sub_type=all, page 1 and page size 1 returned 857 matches for title="OpenHands" and zero for app="OpenHands". The title observation is broad and may include documentation, repositories and non-running deployments. The zero application count does not mean there are no exposed deployments. It means the chosen application fingerprint did not match in this observation. The runtime boundary is the important one The OpenHands architecture documentation notes that the agent server can be configured with session API keys and that sensitive values stored with conversations are encrypted by OH_SECRET_KEY. It also lists API routes and an OpenAPI documentation endpoint. A server with no API authentication is appropriate only when it is isolated to a trusted host or process boundary. A public network path changes that assumption. The web application may hold model-provider keys, a workspace with source code and conversation history. The agent server can execute commands and manipulate files inside its workspace. A user who can reach that runtime without authentication may be able to start work, read session data or alter settings depending on the deployment. This article does not claim a specific exploit against an OpenHands version; it highlights the default-to-exposure review. Test each listener separately From outside the management network, test the UI port, the agent server port and the OpenAPI documentation path. A proxy that authenticates the UI does not necessarily protect a runtime port bound on another interface. Confirm the bind address, container port mapping, firewall rule and proxy route. If session API keys are configured, verify that a request without the expected header is rejected and that keys are not placed in browser-visible configuration. Set a stable OH_SECRET_KEY and protect it like any other application secret. Rotate provider API keys separately from the application secret. Limit the workspace's access to the host filesystem and outbound network. Review Docker socket mounts and host mounts because an agent that can control containers or read broad host paths has authority far beyond editing repository files. Interpret the title count carefully The 857 title matches are useful for finding documentation and public references, not for proving that 857 OpenHands runtimes are reachable. The title field is a visible label and can appear in tutorials, issue pages and marketing content. A zero app count is also not a negative proof. ZoomEye fingerprints are a measurement aid, not a complete census. For owned deployments, build an inventory from process listeners, container mappings and reverse-proxy routes rather than relying on external search. Record the version, image digest, public hostname, authentication mode, session key source and workspace mount. Compare that inventory with the title matches that resolve to your domains. Incident response If a runtime was exposed, preserve its configuration, session keys, workspace contents and command history according to policy. Determine whether an unauthorised actor could start conversations, read stored provider credentials or alter the model endpoint. Rotate provider keys and session API keys, revoke active conversations where supported, and rebuild the runtime from a clean workspace. OpenHands makes agent execution visible and controllable. The security review must make the listener boundary equally visible, because a localhost default is safe only until a deployment changes the bind or publishes it through an unprotected proxy. References - OpenHands local setup - OpenHands agent server architecture - ZoomEye title="OpenHands" count observation
なんかドキュメントが間違ってるっぽいなと思い、今年の6月ぐらいに報告してたっぽくて(自分自身でも正直あんまり覚えてないんだけど)、実際に問題だったみたいでissueのリンクと共に丁寧なお礼メールが来た。役に立てたようでよかったです。 docs#1068 t.co