CVE-2026-101065 in Obot
Summary
by MITRE • 09/28/2026
Obot is an open-source AI agent/MCP platform. In all versions up to and including commit d7e6970, the Docker quickstart command documented in the README starts the container listening on 0.0.0.0:8080 with authentication disabled by default. When authentication is disabled, every request is mapped to a synthetic "nobody" user that holds the Owner and Admin roles, so any unauthenticated party who can reach the exposed port obtains full administrative access to the Obot API and UI, including the ability to register and launch attacker-controlled MCP servers. Because the quickstart also mounts /var/run/docker.sock into the container, the MCP runtime backend reachable this way has access to the host's Docker control surface. The fix is documentation-only: the quickstart now enables authentication, and operators who followed the previous instructions should set OBOT_SERVER_ENABLE_AUTHENTICATION=true before exposing the host to any untrusted network.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified in Obot prior to commit d7e6970 represents a critical misconfiguration of default security settings within its Docker-based quickstart deployment mechanism. The core issue stems from the application binding to all available network interfaces on port 8080 while simultaneously disabling authentication by default. This configuration effectively exposes the entire administrative surface of the Obot platform, which serves as an AI agent and Model Context Protocol (MCP) orchestration layer, to any entity capable of reaching that specific port over the network. In a production or even semi-public development environment, this lack of access control allows unauthenticated actors to interact with the system without providing valid credentials, bypassing fundamental identity verification mechanisms entirely.
From an operational perspective, the absence of authentication results in every incoming request being mapped to a synthetic user account designated as nobody. This synthetic entity is pre-assigned both Owner and Admin roles within the application's authorization model. Consequently, any unauthenticated attacker gains full administrative privileges over the Obot API and its associated web interface. These elevated permissions allow the actor to perform sensitive operations such as modifying system configurations, managing users, and critically, registering and launching custom Model Context Protocol servers under their own control. This capability transforms the vulnerable instance into a tool for further exploitation, enabling the attacker to inject malicious logic or exfiltrate data through the AI agent framework.
The severity of this vulnerability is significantly amplified by the specific runtime environment configuration documented in the quickstart instructions. The Docker container mounts the host's /var/run/docker.sock file directly into the container filesystem. This socket provides a direct interface to the Docker daemon, which controls all aspects of container lifecycle and system resources on the host machine. Because the MCP runtime backend operates with access to this control surface, an attacker who has gained administrative access via the unauthenticated API can leverage it to execute arbitrary commands within other containers or even gain root-level access to the underlying host operating system. This chain of exploitation moves beyond simple application compromise into full infrastructure takeover, allowing for lateral movement and persistent access across the networked environment.
This vulnerability aligns with CWE-287, which describes Improper Authentication, as well as CWE-941, indicating Incorrect Authorization due to the assignment of excessive privileges to an unauthenticated user entity. In terms of offensive security frameworks, this scenario maps directly to MITRE ATT&CK technique T1078, Valid Accounts, where attackers use legitimate credentials or accounts with high privilege levels that were improperly provisioned or secured. Furthermore, the ability to launch arbitrary MCP servers relates to supply chain risks and potential misuse of AI agent capabilities for malicious purposes, highlighting the importance of secure defaults in software distribution packages.
To mitigate this risk, operators must ensure that authentication is explicitly enabled before exposing any Obot instance to untrusted networks. The fix implemented in subsequent commits addresses this by enabling authentication by default in the quickstart configuration. For existing deployments or those using older versions, it is imperative to set the environment variable OBOT_SERVER_ENABLE_AUTHENTICATION to true. Additionally, organizations should review their Docker socket mounting practices and consider implementing network-level access controls such as firewalls or reverse proxies with IP whitelisting to restrict access to only trusted internal subnets if administrative functions are required remotely. Regular security audits of default configurations in open-source projects are essential to prevent similar misconfigurations from leading to severe infrastructure compromises.