CVE-2026-101065: Missing Authentication for Critical Function in obot-platform obot
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.
AI Analysis
Technical Summary
Obot's Docker quickstart command prior to commit d7e6970 disables authentication by default and listens on all network interfaces. This results in every request being treated as an authenticated user with Owner and Admin roles, granting full administrative privileges to unauthenticated parties. Because the container mounts /var/run/docker.sock, attackers can leverage this access to control the host's Docker daemon. The remediation is to enable authentication by setting OBOT_SERVER_ENABLE_AUTHENTICATION=true before exposing the service externally. No code patch was released; the fix is a documentation update.
Potential Impact
Unauthenticated attackers who can reach the exposed port gain full administrative access to the obot API and UI. They can register and launch malicious MCP servers and potentially control the host's Docker daemon via the mounted Docker socket. This leads to complete compromise of the obot platform and potentially the host system.
Mitigation Recommendations
The vendor's fix is documentation-only: operators must enable authentication by setting OBOT_SERVER_ENABLE_AUTHENTICATION=true before exposing the service to untrusted networks. No code patch is available. Operators who followed previous instructions should update their configuration accordingly to prevent unauthorized access.
CVE-2026-101065: Missing Authentication for Critical Function in obot-platform obot
Description
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.
CVSS v4.0
Score 9.3critical
Affected software
obot-platform
obot
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Obot's Docker quickstart command prior to commit d7e6970 disables authentication by default and listens on all network interfaces. This results in every request being treated as an authenticated user with Owner and Admin roles, granting full administrative privileges to unauthenticated parties. Because the container mounts /var/run/docker.sock, attackers can leverage this access to control the host's Docker daemon. The remediation is to enable authentication by setting OBOT_SERVER_ENABLE_AUTHENTICATION=true before exposing the service externally. No code patch was released; the fix is a documentation update.
Potential Impact
Unauthenticated attackers who can reach the exposed port gain full administrative access to the obot API and UI. They can register and launch malicious MCP servers and potentially control the host's Docker daemon via the mounted Docker socket. This leads to complete compromise of the obot platform and potentially the host system.
Mitigation Recommendations
The vendor's fix is documentation-only: operators must enable authentication by setting OBOT_SERVER_ENABLE_AUTHENTICATION=true before exposing the service to untrusted networks. No code patch is available. Operators who followed previous instructions should update their configuration accordingly to prevent unauthorized access.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- VulnCheck
- Date Reserved
- 2026-09-27T16:38:56.428Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6ab98494f7a7c541067b9769
Added to database: 09/27/2026, 21:03:16 UTC
Last enriched: 09/27/2026, 21:17:56 UTC
Last updated: 09/28/2026, 02:25:54 UTC
Views: 14
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.