Obot
Monthly
Obot versions 0.12.0 through 0.26.1 return admin- and power-user-supplied static secrets (API keys, tokens) on MCP catalog entries in plaintext to any user who has been granted that entry through Obot's access-control rules, exposing credentials for abuse against backend services. Affected users need a valid Obot account at basic privilege plus an explicit grant on the target entry, and the entry must actually carry admin-set static configuration values, so anonymous exploitation is not possible and only a subset of catalog entries is reachable in practice; the assessed severity is moderate (CVSS 7.1, confidentiality-only impact with no integrity or availability loss). No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (no CISA KEV listing); the vendor has released a fix in Obot v0.26.2.
An authorization bypass in Obot 0.21.1 through 0.24.1 lets any authenticated account holding the low-privileged 'Basic-role' reach MCP servers that Access Control Rules are meant to protect, because the checkUI deny list omits the /mcp-connect-composite/ route and mcpGateway.Proxy will forward the request once the caller supplies a composite MCP ID. Rated 8.6 (CVSS 4.0; independently assessed as CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), exploitation yields high confidentiality and integrity impact on the reachable MCP tools but requires a valid authenticated session, knowledge of a composite MCP ID, and the existence of ACL-restricted MCP servers, so anonymous abuse is not possible; no public exploit code and no confirmed active exploitation (not in CISA KEV) were identified at time of analysis.
Authorization bypass in Obot before v0.21.1 lets any authenticated user with a known MCP Server ID connect to restricted MCP servers through the /mcp-connect/{id} gateway endpoint, which fails to enforce Access Control Rules and MCP Registry membership. Because the gateway reuses Obot's stored OAuth/API credentials for the upstream server, an attacker in a Basic role or above can invoke that server's tools - reading and writing data in whatever backends those credentials reach - even when administrators explicitly scoped the server to a small group. Independently assessed at CVSS 9.3, this is a genuine high-priority authorization flaw limited to multi-user deployments that register credential-bearing MCP servers and depend on ACRs for isolation; no public exploit code has been identified at time of analysis, and vendor-released patched version 0.21.1 is available.
Obot deployments started with the README's Docker quickstart expose port 0.0.0.0:8080 with authentication disabled, allowing unauthenticated attackers who can reach that port to take full Owner/Admin control of the Obot API and UI. Because every request is mapped to a synthetic 'nobody' user that already holds Owner and Admin roles, an attacker can register and launch attacker-controlled MCP servers, and since the quickstart also mounts /var/run/docker.sock into the container, that control extends to the host's Docker daemon. All versions through commit d7e6970 are affected; the vendor fix is documentation-only (the quickstart now enables authentication), no public exploit code has been identified at time of analysis, and instances are safe only if the operator set OBOT_SERVER_ENABLE_AUTHENTICATION=true or kept port 8080 off untrusted networks.
Server-side request forgery in Obot through v0.22.1 allows an authenticated user holding the Power User, Power User Plus, or Admin role to register a remote MCP server pointing at an arbitrary URL, which Obot then fetches server-side with no destination validation. Because the fetched response is reflected back in Obot's error messages, this is a non-blind SSRF: the attacker can read responses from internal services and, against the cloud metadata endpoint 169.254.169.254, potentially obtain the host's cloud IAM credentials and pivot into the cloud account. Exploitation is role-gated and requires authentication to be enabled with privileged users permitted to register remote MCP servers; there is no public exploit identified at time of analysis, and the issue is fixed in v0.23.0.
OAuth dynamic client registration in Obot through v0.22.1 allows unauthenticated remote attackers to register an OAuth client pointing at an attacker-controlled redirect URI, then harvest an access and refresh token from a logged-in victim who visits a single crafted authorization URL. The minted token carries the victim's full group set and is accepted as a bearer token against any Obot API endpoint the victim can access - not just the requested MCP server - letting the attacker read or modify the victim's resources until the token is revoked. Exploitation is gated by the server running with OBOT_SERVER_ENABLE_AUTHENTICATION=true and by required victim interaction (clicking the link); no public exploit code has been identified at time of analysis. Versions v0.23.0 and later add a consent screen, token scoping to the requesting MCP server, and audience validation.
Obot versions 0.25.0 through 0.25.5 and 0.26.0 can persist stale group memberships after an administrator revokes a user's group in the upstream identity provider, leaving the user with revoked group-based access for roughly ten minutes. The flaw is a race condition (CWE-362) in the auth provider group-refresh path: when two refreshes for the same identity overlap and commit out of order, an older refresh overwrites the newer one and restores memberships that were just removed. It is a genuinely low-priority issue - the CVSS 4.0 score is 2.3 (assessed independently as CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N), exploitation requires an already-authenticated user (PR:L), the timing is not attacker-controllable (AC:H), impact is limited to retaining previously held access rather than gaining new privileges, and the condition self-heals within the group check period; no public exploit code has been identified at time of analysis and there is no CISA KEV entry.
Authorization bypass in Obot 0.26.0 through 0.26.1 lets an authenticated user who matches any configured vMCP (virtual MCP) profile selector read prompts, resources, and resource templates belonging to components that profile never granted them, because profile enforcement in those releases was applied only to tools. Attackers abuse the vMCP owner's shared component connection to reach the ungranted prompt/resource endpoints over the network, yielding limited confidentiality impact with no integrity or availability effect (CVSS 5.3, CWE-863, PR:L, so valid authentication and a profile-segmented vMCP deployment are prerequisites). There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); vendor-released patch v0.26.2 closes the gap.
Unauthenticated disclosure of MCP Registry metadata affects Obot deployments running versions up to and including v0.22.1 when the operator has enabled registry authentication via OBOT_SERVER_ENABLE_REGISTRY_AUTH=true. A single unauthenticated GET request to /v0.1/servers returns 200 OK and exposes the registry inventory - server names, descriptions, repository URLs, icons, and connect URLs - that the operator explicitly intended to place behind authentication, because the authorizer's default-allow logic never matched the registry's top-level /v0.1 prefix. No public exploit code has been identified at time of analysis, and the independent assessment rates this as a low-impact, high-confidence information-disclosure flaw (CVSS v3.1 5.3) rather than the CVSS v4.0 6.9 figure in the CVE record: the per-user ACR filter still limits anonymous callers to entries visible to the anonymous identity, no secret environment or header values are exposed, and connecting to listed servers remains properly auth-protected.
Obot versions 0.12.0 through 0.26.1 return admin- and power-user-supplied static secrets (API keys, tokens) on MCP catalog entries in plaintext to any user who has been granted that entry through Obot's access-control rules, exposing credentials for abuse against backend services. Affected users need a valid Obot account at basic privilege plus an explicit grant on the target entry, and the entry must actually carry admin-set static configuration values, so anonymous exploitation is not possible and only a subset of catalog entries is reachable in practice; the assessed severity is moderate (CVSS 7.1, confidentiality-only impact with no integrity or availability loss). No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (no CISA KEV listing); the vendor has released a fix in Obot v0.26.2.
An authorization bypass in Obot 0.21.1 through 0.24.1 lets any authenticated account holding the low-privileged 'Basic-role' reach MCP servers that Access Control Rules are meant to protect, because the checkUI deny list omits the /mcp-connect-composite/ route and mcpGateway.Proxy will forward the request once the caller supplies a composite MCP ID. Rated 8.6 (CVSS 4.0; independently assessed as CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), exploitation yields high confidentiality and integrity impact on the reachable MCP tools but requires a valid authenticated session, knowledge of a composite MCP ID, and the existence of ACL-restricted MCP servers, so anonymous abuse is not possible; no public exploit code and no confirmed active exploitation (not in CISA KEV) were identified at time of analysis.
Authorization bypass in Obot before v0.21.1 lets any authenticated user with a known MCP Server ID connect to restricted MCP servers through the /mcp-connect/{id} gateway endpoint, which fails to enforce Access Control Rules and MCP Registry membership. Because the gateway reuses Obot's stored OAuth/API credentials for the upstream server, an attacker in a Basic role or above can invoke that server's tools - reading and writing data in whatever backends those credentials reach - even when administrators explicitly scoped the server to a small group. Independently assessed at CVSS 9.3, this is a genuine high-priority authorization flaw limited to multi-user deployments that register credential-bearing MCP servers and depend on ACRs for isolation; no public exploit code has been identified at time of analysis, and vendor-released patched version 0.21.1 is available.
Obot deployments started with the README's Docker quickstart expose port 0.0.0.0:8080 with authentication disabled, allowing unauthenticated attackers who can reach that port to take full Owner/Admin control of the Obot API and UI. Because every request is mapped to a synthetic 'nobody' user that already holds Owner and Admin roles, an attacker can register and launch attacker-controlled MCP servers, and since the quickstart also mounts /var/run/docker.sock into the container, that control extends to the host's Docker daemon. All versions through commit d7e6970 are affected; the vendor fix is documentation-only (the quickstart now enables authentication), no public exploit code has been identified at time of analysis, and instances are safe only if the operator set OBOT_SERVER_ENABLE_AUTHENTICATION=true or kept port 8080 off untrusted networks.
Server-side request forgery in Obot through v0.22.1 allows an authenticated user holding the Power User, Power User Plus, or Admin role to register a remote MCP server pointing at an arbitrary URL, which Obot then fetches server-side with no destination validation. Because the fetched response is reflected back in Obot's error messages, this is a non-blind SSRF: the attacker can read responses from internal services and, against the cloud metadata endpoint 169.254.169.254, potentially obtain the host's cloud IAM credentials and pivot into the cloud account. Exploitation is role-gated and requires authentication to be enabled with privileged users permitted to register remote MCP servers; there is no public exploit identified at time of analysis, and the issue is fixed in v0.23.0.
OAuth dynamic client registration in Obot through v0.22.1 allows unauthenticated remote attackers to register an OAuth client pointing at an attacker-controlled redirect URI, then harvest an access and refresh token from a logged-in victim who visits a single crafted authorization URL. The minted token carries the victim's full group set and is accepted as a bearer token against any Obot API endpoint the victim can access - not just the requested MCP server - letting the attacker read or modify the victim's resources until the token is revoked. Exploitation is gated by the server running with OBOT_SERVER_ENABLE_AUTHENTICATION=true and by required victim interaction (clicking the link); no public exploit code has been identified at time of analysis. Versions v0.23.0 and later add a consent screen, token scoping to the requesting MCP server, and audience validation.
Obot versions 0.25.0 through 0.25.5 and 0.26.0 can persist stale group memberships after an administrator revokes a user's group in the upstream identity provider, leaving the user with revoked group-based access for roughly ten minutes. The flaw is a race condition (CWE-362) in the auth provider group-refresh path: when two refreshes for the same identity overlap and commit out of order, an older refresh overwrites the newer one and restores memberships that were just removed. It is a genuinely low-priority issue - the CVSS 4.0 score is 2.3 (assessed independently as CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N), exploitation requires an already-authenticated user (PR:L), the timing is not attacker-controllable (AC:H), impact is limited to retaining previously held access rather than gaining new privileges, and the condition self-heals within the group check period; no public exploit code has been identified at time of analysis and there is no CISA KEV entry.
Authorization bypass in Obot 0.26.0 through 0.26.1 lets an authenticated user who matches any configured vMCP (virtual MCP) profile selector read prompts, resources, and resource templates belonging to components that profile never granted them, because profile enforcement in those releases was applied only to tools. Attackers abuse the vMCP owner's shared component connection to reach the ungranted prompt/resource endpoints over the network, yielding limited confidentiality impact with no integrity or availability effect (CVSS 5.3, CWE-863, PR:L, so valid authentication and a profile-segmented vMCP deployment are prerequisites). There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); vendor-released patch v0.26.2 closes the gap.
Unauthenticated disclosure of MCP Registry metadata affects Obot deployments running versions up to and including v0.22.1 when the operator has enabled registry authentication via OBOT_SERVER_ENABLE_REGISTRY_AUTH=true. A single unauthenticated GET request to /v0.1/servers returns 200 OK and exposes the registry inventory - server names, descriptions, repository URLs, icons, and connect URLs - that the operator explicitly intended to place behind authentication, because the authorizer's default-allow logic never matched the registry's top-level /v0.1 prefix. No public exploit code has been identified at time of analysis, and the independent assessment rates this as a low-impact, high-confidence information-disclosure flaw (CVSS v3.1 5.3) rather than the CVSS v4.0 6.9 figure in the CVE record: the per-user ACR filter still limits anonymous callers to entries visible to the anonymous identity, no secret environment or header values are exposed, and connecting to listed servers remains properly auth-protected.