Obot EUVD-2026-88030

Exploitation requires the operator to have deployed via the documented Docker quickstart (which sets 0.0.0.0:8080 with authentication disabled, OBOT_SERVER_ENABLE_AUTHENTICATION unset/false) AND to have exposed port 8080 to a reachable/untrusted network. Under those conditions no attacker credentials or user interaction are needed - every request is mapped to the 'nobody' Owner/Admin user. The host-Docker escalation additionally requires the quickstart's default /var/run/docker.sock mount to be in place. Limiting factors: an operator who bound to localhost, placed the port behind a firewall/reverse-proxy auth, or set OBOT_SERVER_ENABLE_AUTHENTICATION=true is not exploitable; the documentation-only fix does not remediate already-running instances.

The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N/VC:H/VI:H/VA:H, base 9.3) accurately reflects that any network party reaching the exposed port gains full Owner/Admin access with no authentication or user interaction - and because the quickstart also mounts /var/run/docker.sock, the impact extends to host Docker control (i.e., host compromise), which the vendor's SC:N/SI:N/SA:N arguably understates. The critical countervailing signal is that this is NOT a code flaw but an insecure-default in the documented Docker quickstart: exploitation only affects operators who (a) followed the previous README instructions and (b) exposed port 8080 to an untrusted network. There is no EPSS score, no CISA KEV listing, and no published proof-of-concept in the provided data, so there is no evidence of active or widespread exploitation. Net: the technical impact is genuinely critical (unauth admin + host Docker escape), but real-world priority is bounded by the niche product footprint and the operator-deployment precondition. This is a real 'fix your deployment now' issue for anyone running the quickstart on an exposed host, not a mass-exploitation emergency. The fix is documentation-only - operators must set OBOT_SERVER_ENABLE_AUTHENTICATION=true - so patching a version does not automatically remediate already-deployed instances.

An operator follows Obot's documented Docker quickstart, which binds the container to 0.0.0.0:8080 with authentication disabled, and exposes the host to a network. An unauthenticated attacker who reaches the port is silently mapped to the synthetic 'nobody' user holding Owner and Admin roles, giving full API/UI control; they register and launch an attacker-controlled MCP server whose runtime backend can reach the mounted /var/run/docker.sock, pivoting to full host Docker control. No public exploit code is identified in the provided data, but exploitation requires only standard HTTP tooling.