CVE-2026-101065: Obot AI Agent Platform Ships With Authentication Disabled by Default

Overview

Obot is an open-source AI agent and Model Context Protocol (MCP) platform used to build and run tool-using AI agents. CVE-2026-101065 is not a bug in Obot's authentication code — it is a default-configuration failure in the platform's own officially documented onboarding path. The Docker quickstart command published in Obot's README starts the container listening on 0.0.0.0:8080 with authentication disabled by default, and separately mounts /var/run/docker.sock into the container for the MCP runtime backend.

The combination is severe enough to earn a CVSS v3.1 score of 9.8 (Critical): any unauthenticated party who can reach the exposed port gets full administrative control of the Obot instance, and from there a plausible path to the underlying Docker host itself. The flaw was published September 27, 2026 and is tracked under CWE-306 (Missing Authentication for Critical Function).

Technical Details

Exploitation status: No public proof-of-concept had been indexed and the CVE does not appear in CISA's Known Exploited Vulnerabilities (KEV) catalog as of publication — treat the absence of a known exploit as a head start on remediation, not as a reason to deprioritize it.

How It Works

Obot's quickstart is meant to get a new user from zero to a running agent platform with a single Docker command. To make that first-run experience frictionless, the quickstart configuration ships with OBOT_SERVER_ENABLE_AUTHENTICATION effectively off. When authentication is disabled, Obot doesn't simply leave the login page unlocked — it maps every incoming request to a synthetic "nobody" user that holds both the Owner and Admin roles. There is no reduced-privilege anonymous mode; the unauthenticated default identity is the most powerful account on the system.

That alone would let any network-reachable, unauthenticated caller:

• Access the full Obot administrative API and UI.
• Register and launch attacker-controlled MCP servers — meaning an attacker doesn't just view data, they can wire up new tool integrations that the platform will then execute with Owner/Admin authority.

The quickstart compounds the exposure by also mounting the host's /var/run/docker.sock into the container so Obot's MCP runtime backend can manage its own containers. A caller who reaches Obot's unauthenticated admin surface and can pivot into that MCP runtime therefore has a credible path to the Docker socket — and control of the Docker socket is functionally equivalent to root on the host, since it can be used to launch privileged containers with the host filesystem mounted in.

Because the only precondition is network reachability to port 8080 — no credentials, no user interaction, no prior foothold — the practical risk is entirely a function of how the instance was deployed: a quickstart left bound to a public interface, a permissive cloud security group, or a Docker port mapping that reaches beyond localhost turns this into a same-day, zero-effort compromise.

Impact Assessment

Who Is At Risk

Anyone who followed Obot's README quickstart instructions to stand up an instance and exposed port 8080 beyond their own trusted loopback or private network — including instances placed behind a reverse proxy that doesn't independently enforce authentication, or bound to 0.0.0.0 on a host with a routable IP or an open cloud security group.

Potential Attack Chains

1. Direct admin takeover — Attacker sends unauthenticated requests to the exposed Obot API and is transparently granted Owner/Admin-equivalent access as the "nobody" identity.
2. Malicious MCP server registration — Attacker registers a rogue MCP server through the now-open admin interface, giving them a foothold that executes with the platform's full authority.
3. Docker socket pivot — From the MCP runtime backend, the attacker leverages the mounted /var/run/docker.sock to launch a new container with the host root filesystem bind-mounted, achieving host-level code execution.
4. Full host compromise — With host-level access, the attacker can pivot laterally, exfiltrate any data reachable from the host, and persist well beyond the Obot application itself.

Mitigation

Immediate Actions

• Explicitly set OBOT_SERVER_ENABLE_AUTHENTICATION=true on every Obot instance deployed via the Docker quickstart, regardless of when it was stood up — the fix for this CVE is a documentation change to the quickstart, not a forced code-level patch, so existing instances are not automatically remediated.
• Never bind Obot's port to 0.0.0.0 on a host reachable from an untrusted network. Restrict it to localhost or an internal-only interface and put a properly authenticated reverse proxy in front of it if remote access is required.
• Audit whether /var/run/docker.sock needs to be mounted into the Obot container at all for your deployment; if the MCP runtime backend can be run without host Docker socket access, remove the mount.

Detection Opportunities

• Review Obot access logs for administrative API calls (MCP server registration, user/role management) with no corresponding authenticated session — a hallmark of the "nobody" Owner/Admin identity being used.
• Check container runtime logs and Docker daemon audit logs for containers launched by the Obot process that were not initiated through a known, authenticated workflow.
• Scan externally for exposed Obot instances (default port 8080) using internal or third-party attack-surface-management tooling.

Defence-in-Depth

• Treat any AI agent or MCP orchestration platform as a high-value target by default — these platforms are explicitly designed to execute arbitrary tool calls, which makes an authentication bypass on one categorically more dangerous than on a typical CRUD application.
• Apply network segmentation so that even a fully compromised Obot instance cannot reach the Docker socket, other production services, or sensitive internal APIs.
• Keep Obot and its MCP runtime components current; this is the second Obot advisory disclosed alongside CVE-2026-101084 (see CosmicBytez Labs' coverage) in the same release window, indicating active scrutiny of the platform's access-control model.

Background

CVE-2026-101065 was disclosed September 27, 2026 as GitHub Security Advisory GHSA-jj4w-pfgv-4mrm, alongside a second Obot advisory, CVE-2026-101084, covering an authorization bypass in the /mcp-connect gateway endpoint. Both stem from the same broader theme: Obot's rapid on-ramp for AI agent deployment prioritized ease of first-run setup over safe defaults, and its MCP gateway's authorization model had gaps between how different code paths checked access. Neither issue requires an existing account compromise to matter — CVE-2026-101065 is exploitable pre-authentication by design, since the "authentication" the platform relies on can be switched off entirely by a quickstart default.

Organizations running self-hosted AI agent and MCP infrastructure should treat this disclosure as a reminder that agent platforms sit at a uniquely sensitive point in the stack: they are built to execute code and call external tools on behalf of whoever can reach them, so a missing-authentication flaw here has a materially larger blast radius than the same flaw in a conventional web application.

References

• NVD — CVE-2026-101065
• GitHub Security Advisory — GHSA-jj4w-pfgv-4mrm