CVE-2026-101065: Obot Docker Quickstart Exposes Admin API on 0.0.0.0:8080 — Detection and Remediation Guide

NVD has published CVE-2026-101065, a CVSS 9.8 (Critical), network-exploitable vulnerability affecting Obot, an open-source AI agent and MCP (Model Context Protocol) server platform. This is not a memory-corruption bug or a race condition — it is a fundamentally dangerous default configuration shipped in the project's own documentation. In all versions up to and including commit d7e6970, the Docker quickstart command in the Obot README starts the container listening on 0.0.0.0:8080 with authentication disabled by default.

Here is the part that should get your attention: when authentication is disabled, every inbound request is mapped to a synthetic nobody user that holds the Owner and Admin roles. Any unauthenticated party who can reach the exposed port gets 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 the host's Docker socket (/var/run/docker.sock) into the container, an attacker who compromises Obot can pivot directly to container and host-level control. On an internet-exposed host, this is a one-request path from anonymous network access to remote code execution on your infrastructure.

If your team has been experimenting with AI agent platforms — and in 2026, most teams have — you need to sweep for exposed Obot instances today. Shadow AI deployments stood up by developers following a README quickstart are exactly the kind of asset that never makes it into your CMDB.

Technical Analysis

Affected Products and Versions

• Product: Obot (open-source AI agent / MCP platform)
• Affected versions: All versions up to and including commit d7e6970
• Deployment vector: Docker quickstart command as documented in the project README
• CVE: CVE-2026-101065
• CVSS v3.1: 9.8 (Critical) — vector pathway NETWORK (per NVD: AV:N/AC:L/PR:N/UI:N)
• Reference: https://nvd.nist.gov/vuln/detail/CVE-2026-101065

Root Cause

The vulnerability is a composite of three dangerous defaults in the documented quickstart:

1. Bind address 0.0.0.0:8080. The container publishes its API/UI port on all interfaces, not localhost. On any cloud VM or host with a public IP, the service is internet-reachable the moment the container starts.
2. Authentication disabled by default. Rather than failing closed, Obot's unauthenticated mode maps every request to a synthetic nobody identity. Critically, that identity is not a read-only guest — it carries Owner and Admin roles. This turns "auth disabled" into "auth bypassed with maximum privilege."
3. Docker socket mounted into the container. The quickstart mounts /var/run/docker.sock, giving processes inside the container full control over the Docker daemon. Combined with admin access to the MCP server registration feature, an attacker can launch attacker-controlled MCP servers and use the mounted socket to spawn privileged containers, mount the host filesystem, and achieve host-level code execution.

Attack Chain (Defender's View)

1. Attacker scans for TCP/8080 or fingerprints the Obot UI/API (Shodan/Censys exposure of AI tooling ports has exploded over the past year).
2. Unauthenticated HTTP request hits the API; the request is processed as the nobody user with Owner/Admin roles.
3. Attacker registers a malicious MCP server definition pointing at attacker-controlled infrastructure or a local payload.
4. Obot launches the MCP server inside the container — attacker code now executes in the Obot container context.
5. Attacker uses the mounted /var/run/docker.sock to spawn a privileged container with host mounts, escalating to full host compromise.

Exploitation Status

As of publication, NVD lists CVE-2026-101065 with no confirmed CISA KEV entry, but treat exploitation likelihood as high. This is a zero-skill exploit: it requires no crafted payload, no race condition, no auth token — just a network path to TCP/8080. AI agent platforms are under active scanning pressure in 2026, and any instance reachable from the internet should be assumed compromised until proven otherwise. If you find an exposed instance that has been up for more than a few days, escalate to incident response rather than simple remediation.

Detection & Response

Sigma Rules

The following rules target the two highest-fidelity observable behaviors: (1) Docker containers launched with the Obot image, the dangerous port mapping, and auth disabled; and (2) any container launched with the Docker socket mounted — a strong pre compromise and post-exploitation pivot indicator.

---
title: Obot Container Launched with Authentication Disabled and Public Bind
id: 3f8a1c94-7b2e-4d51-9c6a-8e0f2a5b7d31
status: experimental
description: Detects Docker run/compose commands that launch the Obot AI agent platform bound to 0.0.0.0:8080 with authentication disabled, matching the CVE-2026-101065 vulnerable quickstart configuration.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-101065
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_image:
    CommandLine|contains:
      - 'obot'
      - 'ghcr.io/obot'
  selection_bind:
    CommandLine|contains:
      - '8080:8080'
      - '-p 8080'
      - '0.0.0.0:8080'
  selection_auth:
    CommandLine|contains:
      - 'OBOT_SERVER_AUTH_ENABLED=false'
      - 'AUTH_ENABLED=false'
      - '--auth-enabled=false'
  condition: selection_image and (selection_bind or selection_auth)
falsepositives:
  - Developers intentionally running Obot on isolated lab networks
level: high
---
title: Docker Container Launched with Docker Socket Mount
id: 9c2e5b17-4a6d-4f83-b1e9-5d7c0a3f8e42
status: experimental
description: Detects Docker containers launched with /var/run/docker.sock mounted, a container escape and host-takeover primitive used in the CVE-2026-101065 attack chain after Obot admin compromise.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-101065
  - https://attack.mitre.org/techniques/T1611/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1611
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    CommandLine|contains:
      - '/var/run/docker.sock'
      - 'docker.sock'
  filter_known:
    CommandLine|contains:
      - 'portainer'
      - 'watchtower'
      - 'traefik'
  condition: selection and not filter_known
falsepositives:
  - Legitimate container management tooling (Portainer, Watchtower) - maintain and tune the filter list for your environment
level: medium

KQL (Microsoft Sentinel / Defender)

The following query hunts across Syslog/CEF-ingested Linux hosts and Defender for Endpoint process telemetry for Obot deployments launched with the vulnerable quickstart flags. Run it over at least 30 days — shadow AI tooling is frequently stood up weeks before anyone notices.

let obotIndicators = dynamic(["obot", "ghcr.io/obot", "8080:8080", "0.0.0.0:8080", "AUTH_ENABLED=false", "docker.sock"]);
union isfuzzy=true
(Syslog
| where TimeGenerated > ago(30d)
| where SyslogMessage has_any (obotIndicators)
| project TimeGenerated, Computer, ProcessName, SyslogMessage, Source = "Syslog"),
(DeviceProcessEvents
| where TimeGenerated > ago(30d)
| where ProcessCommandLine has_any (obotIndicators)
| project TimeGenerated, Computer = DeviceName, ProcessName = FileName, SyslogMessage = ProcessCommandLine, Source = "MDE"),
(CommonSecurityLog
| where TimeGenerated > ago(30d)
| where Message has_any (obotIndicators)
| project TimeGenerated, Computer = DeviceName, ProcessName = ApplicationProtocol, SyslogMessage = Message, Source = "CEF")
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Sources = make_set(Source) by Computer, ProcessName, SyslogMessage
| order by FirstSeen desc

For network-side exposure confirmation, also review inbound connection telemetry to TCP/8080 on hosts you did not know were running Obot — an established external session to that port is your triage trigger, not just the container's existence.

Velociraptor VQL

This hunt artifact identifies hosts with processes listening on 0.0.0.0:8080 and cross-references running Docker containers that have the Docker socket mounted — the two forensic pillars of this vulnerability.

-- Hunt for Obot exposure: listeners on 0.0.0.0:8080 and containers with docker.sock mounts
LET listeners = SELECT Pid, Name, Address, Port, Status
FROM netstat()
WHERE Port = 8080 AND (Address =~ '0.0.0.0' OR Address =~ '::')

LET dockerprocs = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'docker|containerd|obot'

SELECT * FROM listeners
UNION ALL
SELECT Pid, Name, CommandLine AS Address, NULL AS Port, 'PROCESS' AS Status
FROM dockerprocs
WHERE CommandLine =~ 'docker.sock|8080:8080|AUTH_ENABLED'

Remediation / Verification Script

Run this on any Linux host where Docker is deployed. It identifies running Obot containers, checks for the dangerous bind/auth/socket-mount configuration, and optionally stops exposed instances.

#!/bin/bash
# CVE-2026-101065 - Obot exposure verification and containment script
# Run with sudo on any Docker host. Add --stop to immediately stop exposed containers.

STOP_CONTAINERS=false
[ "$1" = "--stop" ] && STOP_CONTAINERS=true

echo "=== CVE-2026-101065 Obot Exposure Check ==="

# 1. Find running Obot containers
OBOT_CONTAINERS=$(docker ps --format '{{.ID}} {{.Image}} {{.Names}}' | grep -i obot)
if [ -z "$OBOT_CONTAINERS" ]; then
  echo "[OK] No running Obot containers found."
else
  echo "[ALERT] Running Obot containers detected:"
  echo "$OBOT_CONTAINERS"
  for CID in $(docker ps -q --filter "ancestor=$(docker ps --format '{{.Image}}' | grep -i obot | head -1)"); do
    echo "--- Inspecting $CID ---"
    # Check published ports for 0.0.0.0 binding
    docker inspect "$CID" --format '{{json .HostConfig.PortBindings}} {{json .NetworkSettings.Ports}}'
    # Check for docker.sock mount
    docker inspect "$CID" --format '{{json .Mounts}}' | grep -q 'docker.sock' && echo "[CRITICAL] docker.sock is mounted into this container"
    # Check auth-related environment
    docker inspect "$CID" --format '{{json .Config.Env}}' | grep -i 'auth' || echo "[WARN] No auth configuration found in container env (likely running unauthenticated)"
    $STOP_CONTAINERS && docker stop "$CID" && echo "[ACTION] Stopped container $CID"
  done
fi

# 2. Check for any listener on 0.0.0.0:8080
echo "--- Checking listeners on TCP/8080 ---"
ss -tlnp | grep ':8080' || echo "[OK] Nothing listening on 8080"

# 3. Check any container (Obot or not) with docker.sock mounted
echo "--- Checking all containers for docker.sock mounts ---"
for CID in $(docker ps -q); do
  docker inspect "$CID" --format '{{.Name}} {{json .Mounts}}' | grep -q 'docker.sock' && \
    echo "[WARN] $(docker inspect "$CID" --format '{{.Name}}') has docker.sock mounted"
done

# 4. Check host firewall for open 8080
echo "--- Firewall exposure check ---"
(iptables -L INPUT -n 2>/dev/null | grep 8080) || (nft list ruleset 2>/dev/null | grep 8080) || echo "No explicit 8080 firewall rules found (check cloud security groups separately)"

echo "=== Check complete. If [ALERT] or [CRITICAL] appeared, treat the host as potentially compromised. ==="

Remediation

Immediate (today):

1. Find every Obot instance. Run the script above across your Docker hosts, and query your EASM/external attack surface tooling (or Shodan/Censys) for your public IP space exposing Obot's UI on TCP/8080. Do not assume you know where developers stood this up.
2. Stop or firewall exposed instances. If an instance is reachable beyond localhost, stop the container or restrict access immediately. At minimum, rebind to 127.0.0.1:8080 or place it behind an authenticated reverse proxy/VPN.
3. Enable authentication. Obot supports authentication providers — configure one (e.g., OIDC against your IdP) before exposing the service to any network. Verify post-change that unauthenticated requests receive 401/403 rather than being mapped to the nobody Owner/Admin identity.

Short-term (this week):

4. Update to a fixed version. Pull the latest Obot release/commit beyond d7e6970 — track the project's repository and the NVD entry (https://nvd.nist.gov/vuln/detail/CVE-2026-101065) for the vendor's patched quickstart and any changed default behavior. Re-pull images rather than assuming a running container picked up fixes.
5. Remove the Docker socket mount. There is almost never a legitimate need for an AI agent platform to control the Docker daemon. If the workload genuinely requires container orchestration, use a scoped, rootless, or socket-proxy approach (e.g., a socket proxy exposing only the specific API endpoints required) rather than the raw socket.
6. Assume compromise on previously exposed instances. If TCP/8080 was internet-reachable, pull container logs and audit the MCP server registry for entries you did not create. Review spawned containers, image pulls, and any processes that touched docker.sock. Rotate any credentials, API keys, or model provider tokens that were configured in the platform — an admin attacker had full read access to all of them.

Strategic:

7. Govern AI tooling like production software. The fastest-growing exposure class we see in 2026 engagements is developer-deployed AI infrastructure stood up from README quickstarts. Extend your asset inventory, vulnerability scanning, and container policy enforcement (e.g., admission control blocking docker.sock mounts and 0.0.0.0 binds) to cover these workloads.
8. Default-deny egress for AI agent platforms. MCP server registration means these platforms are designed to make outbound connections to arbitrary endpoints. Restrict egress to an allowlist so that even a successful admin compromise cannot easily reach attacker infrastructure.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub