Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
In affected versions, the URL of a remote MCP server is attacker-controlled at registration and is fetched server-side with no validation of the destination. There is no guard against loopback, link-local, RFC1918 private ranges, or the cloud metadata endpoint (169.254.169.254), so a use with the Power User, Power User Plus, or Admin role can coerce Obot into making requests to internal services and to the cloud instance metadata service, and read the responses. Am I affected? You are affected if you run Obot <= v0.22.1 with authentication enabled and allow privileged users (with the Power User or higher privileges) to register remote MCP servers . The metadata-sync code path that triggers the fetch runs automatically during reconciliation, so no user interaction beyond registration is required. Details A remote server's URL (RemoteRuntimeConfig.URL) is accepted at registration after only checking that it is parseable and uses an http/https scheme — the destination is never…
Recommended action: Upgrade to 0.23.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions, enabling registry authentication (OBOTSERVERENABLEREGISTRYAUTH=true) does not actually protect the MCP Registry endpoints under /v0.1/ — they remain readable by unauthenticated callers. Am I affected? You are affected if you run Obot <= v0.22.1 with OBOTSERVERENABLEREGISTRYAUTH=true. An unauthenticated GET /v0.1/servers returns 200 OK with catalog server metadata. (With registry auth disabled, the registry is intentionally public and this is not a defect.) Details The authorizer rejects a fixed set of known-protected prefixes and then default-allows everything else. The registry is mounted at the top-level /v0.1 prefix, which was not in that set, so anonymous requests were authorized before the WWW-Authenticate challenge for /v0.1 was ever reached. The registry handler still applies its own per-user ACR filtering, so an anonymous caller receives only entries accessible to the anonymous identity (e.g. default-catalog/wildcard entries), and responses…
Recommended action: Upgrade to 0.23.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions, an unauthenticated attacker could register an OAuth client with an arbitrary external redirect URI, and the authorization flow would auto-complete without a consent screen. If a logged-in victim visited a crafted authorization URL, an authorization code was delivered to the attacker's redirect URI and exchanged for an access token. That token was minted with the victim's full set of groups, so it could be used as a bearer token against the Obot API endpoints the victim had access to — rather than being scoped to just the requested MCP server. Am I affected? You are affected if you run Obot <= v0.22.1 with OBOTSERVERENABLEAUTHENTICATION=true. Exploitation requires a logged-in victim to visit a single attacker-controlled authorization URL. Details Three issues combined to create this vulnerability. First, OAuth dynamic client registration was reachable without authentication and applied no restriction on the redirect URIs a client could register, so an…
Recommended action: Upgrade to 0.23.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If you have the MCP Server ID, you can connect to the MCP server even if you don't have permissions to the server. The MCP gateway endpoint /mcp-connect/{mcpid} does not enforce Access Control Rules (ACRs). Any authenticated Obot user who possesses an MCP Server ID can connect to that server through the gateway — including making tool calls — regardless of whether they are a member of any MCP Registry that grants access to the server. In practice this means any User can fully use MCP servers that the administrator believed were restricted to specific groups. Severity Reporter estimate: Critical. | CVSS 3.1 metric | Value | |---|---| | Attack Vector | Network | | Attack Complexity | Low | | Privileges Required | Low (authenticated Obot user, any role ≥ Basic) | | User Interaction | None | | Scope | Changed (Obot authorization bypass enables access to data and operations on an upstream third-party service via Obot's stored OAuth credentials) | | Confidentiality | High | |…
Recommended action: Upgrade to 0.21.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.