Advisory · CVE-2026-101065
Obot quickstart runs with authentication off, granting admin to anyone who reaches it
The documented Obot Docker quickstart listened on 0.0.0.0:8080 with auth disabled, mapping every request to an Owner-role synthetic user, while mounting the host Docker socket.
- Vendor
- obot-platform
- Product
- Obot
- Identifier / CWE
- CVE-2026-101065
CWE-306 - Action timing
- Immediate
Explain it like I’m five
Obot's quickstart left the front door unlocked and handed every visitor a master key. Worse, the key ring also opened the garage, which held the keys to the entire building: the host's Docker controls.
- 01Auth-off quickstart
The README's Docker quickstart started the container on 0.0.0.0:8080 with authentication disabled by default.
- 02Synthetic admin
With auth disabled, every request was mapped to a synthetic 'nobody' user holding Owner and Admin roles.
- 03Open admin access
Anyone able to reach the exposed port got full administrative access to the Obot API and UI, including registering and launching attacker-controlled MCP servers.
- 04Docker socket in reach
The quickstart also mounted /var/run/docker.sock, so the MCP runtime reachable this way had access to the host's Docker control surface.
What happened
Obot, the open-source AI agent and MCP platform, shipped a Docker quickstart (affecting versions through commit d7e6970) that started the container listening on 0.0.0.0:8080 with authentication disabled by default. With authentication off, every request was mapped to a synthetic “nobody” user holding the Owner and Admin roles, so any unauthenticated party able to reach the exposed port obtained full administrative access to the Obot API and UI, including the ability to register and launch attacker-controlled MCP servers.
Compounding the exposure, the quickstart mounted /var/run/docker.sock into the container, so the MCP runtime backend reachable through this path had access to the host’s Docker control surface.
The fix is documentation-only: the quickstart now enables authentication. Operators who followed the previous instructions should set OBOT_SERVER_ENABLE_AUTHENTICATION=true before exposing the host to any untrusted network.
What to do
- Identify Obot deployments that were started from the Docker quickstart before the fix.
- Set OBOT_SERVER_ENABLE_AUTHENTICATION=true and redeploy, and verify that port 8080 is not reachable from untrusted networks.
- Determine whether the admin port was exposed beyond trusted networks; if it was, assume the instance was compromised.
- Audit MCP servers registered, tools launched, and actions taken on the instance during the exposure window.
- Rotate any credentials, tokens, or secrets reachable from the instance, and rebuild the host if an attacker could have reached docker.sock through it.
Management note
This is a default-insecure deployment pattern, not a code bug in a corner: the official instructions produced an internet-facing admin with host-level reach. Treat every quickstart-based deployment as suspect until it is reconfigured and audited, and make authentication-enabled-by-default a checklist item for any platform your teams adopt.