CVE-2026-101063 in Obot
Summary
by MITRE • 09/28/2026
Obot versions before v0.23.0 fail to enforce authentication on MCP Registry endpoints under /v0.1/* when registry authentication is enabled. Unauthenticated attackers can read registry metadata including server names, descriptions, repository URLs, and connect URLs by sending GET requests to /v0.1/servers.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified in Obot versions prior to v0.23.0 represents a critical failure in access control mechanisms within the Model Context Protocol (MCP) Registry implementation. Specifically, the application fails to enforce authentication requirements on API endpoints located under the /v0.1/* path when registry-level authentication is explicitly enabled by the administrator. This misconfiguration allows unauthenticated actors to interact with sensitive management interfaces that should be restricted to authorized personnel or services. The core technical flaw lies in the middleware or routing logic of the Obot server, which does not properly validate session tokens, API keys, or other credential-based proofs of identity for requests targeting these specific registry endpoints. Consequently, the security boundary intended by the configuration setting is effectively bypassed due to a logical error in how authentication checks are applied across different URL prefixes within the application architecture.
The operational impact of this vulnerability centers on the unauthorized disclosure of sensitive registry metadata. By sending simple GET requests to the /v0.1/servers endpoint, an attacker can retrieve comprehensive details about the MCP servers registered with the Obot instance. This data includes server names, descriptive information, repository URLs, and connect URLs. While these fields may not contain direct credentials or source code, they provide a detailed map of the organization's AI infrastructure and integration points. Attackers can use this intelligence to identify potential targets for further exploitation, such as locating vulnerable endpoints within the referenced repositories or understanding the network topology associated with specific server names. This information gathering phase significantly lowers the barrier for subsequent attacks, including social engineering campaigns targeting administrators who manage these servers or reconnaissance efforts aimed at discovering additional weaknesses in the connected systems.
From a classification perspective, this vulnerability aligns closely with CWE-287, which denotes Improper Authentication, as the system fails to correctly verify the identity of users attempting to access protected resources. It also relates to CWE-601, URL Redirection to Untrusted Site, if the connect URLs or repository links lead to external domains that could be manipulated for phishing or malware distribution, although the primary issue is information disclosure rather than redirection itself. In terms of offensive security frameworks, this behavior corresponds to ATT&CK technique T1592, Gather Victim Host Information, where adversaries collect details about a target's infrastructure to plan further operations. The lack of authentication on these specific endpoints creates an asymmetry in access control that undermines the overall security posture of the MCP Registry deployment.
To mitigate this vulnerability, organizations running Obot versions before v0.23.0 should immediately upgrade to version 0.23.0 or later, where the authentication enforcement logic has been corrected for all relevant endpoints under /v0.1/*. For environments that cannot be upgraded instantly due to operational constraints, temporary mitigations include implementing a reverse proxy configuration such as Nginx or Apache in front of the Obot instance. This external layer can enforce strict access control policies by requiring valid authentication headers before forwarding requests to the backend application for any path starting with /v0.1/. Additionally, network segmentation strategies should be reviewed to ensure that these registry endpoints are not exposed directly to untrusted networks without intermediate security controls. Regular auditing of API endpoint permissions and automated testing using vulnerability scanners configured to check for broken access control flaws can help detect similar misconfigurations in other parts of the application stack before they are exploited by malicious actors.