CVE-2026-101062
HighCVSS 8.8Summary
Obot before v0.23.0 (affected versions <= v0.22.1) with OBOT_SERVER_ENABLE_AUTHENTICATION=true exposes OAuth dynamic client registration without authentication and without redirect URI restrictions. An attacker can register a client pointing to their domain and steal the authorization code of a logged-in victim, then exchange it for access and refresh tokens. The MCP OAuth token carries the victim's full group set in the JWT, and Obot validates only the issuer, not the audience, allowing the token to be used as a bearer token against any Obot API endpoint the victim can access.
Risk Assessment
Attackers can steal the victim's access and refresh tokens, allowing them to read or modify the victim's resources in Obot until the token is revoked.
Recommendation
Upgrade Obot to v0.23.0, which adds a consent screen, restricts MCP OAuth tokens to the specific MCP, and enforces audience validation.
Other vulnerabilities in Obot
See all- CVE-2026-101064High
Obot before v0.23.0 contains a server-side request forgery vulnerability in remote MCP server registration that allows privileged users to specify arbitrary URLs without destination validation. Attackers with Power User or higher roles can coerce Obot to make requests to internal services and cloud metadata endpoints, reading responses in error messages to disclose sensitive credentials.
- CVE-2026-101063Medium
Obot versions before v0.23.0 fail to enforce authentication on MCP Registry endpoints under /v0.1/* when registry authentication is enabled. An unauthenticated attacker can read registry metadata including server names, descriptions, repository URLs, and connect URLs by sending GET requests to /v0.1/servers.
- CVE-2026-101084Critical
obot versions before v0.21.1 fail to enforce Access Control Rules on the /mcp-connect endpoint, allowing any authenticated user to connect to restricted MCP servers if they possess the server ID. Attackers can bypass authorization to access sensitive backend systems.
- CVE-2026-101065Critical
Obot up to commit d7e6970, when started via the Docker quickstart from README, listens on 0.0.0.0:8080 with authentication disabled. Every request is mapped to a synthetic 'nobody' user with Owner and Admin roles, granting full administrative access. The quickstart also mounts /var/run/docker.sock, giving access to the host's Docker control surface.
Original NVD description (English source)
Obot before v0.23.0 (affected versions <= v0.22.1) running with OBOT_SERVER_ENABLE_AUTHENTICATION=true exposes OAuth dynamic client registration without authentication and without any restriction on the redirect URIs a client may register. Because the authorization flow auto-completes for an already logged-in user with no consent screen, an attacker who registers a client pointing at their own domain and induces a logged-in victim to visit a single crafted authorization URL receives an authorization code at the attacker-controlled redirect URI and can exchange it for an access token and refresh token. The token minted by the MCP OAuth flow carries the victim's full group set in the JWT, and Obot validated only the issuer and not the audience, so the token is accepted as a bearer token against any Obot API endpoint the victim can access rather than being scoped to the requested MCP server, allowing the attacker to read or modify the victim's resources until the token is revoked. v0.23.0 adds a consent screen, restricts MCP OAuth tokens to the MCP involved in the request, and enforces audience validation.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS