Description

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 checks to access and manipulate sensitive backend systems through MCP tool calls using stored OAuth credentials.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.6",
  "pubDate": "2026-09-27T21:17:02.163Z",
  "pubdate": "2026-09-27T21:17:02.163Z",
  "executiveSummary": "A critical improper access control vulnerability exists in the obot platform, specifically within the /mcp-connect endpoint.\nThe vulnerability allows authenticated users to bypass authorization mechanisms and interact with restricted Model Context Protocol (MCP) servers.\nBy submitting a known server ID, an attacker can illicitly connect to backend systems that should otherwise be protected by enforced Access Control Rules.\nThis flaw impacts obot versions prior to v0.21.1 and poses a significant risk to data integrity and system security.\nAn attacker with standard authenticated access can leverage stored OAuth credentials to execute arbitrary tool calls, potentially leading to unauthorized data manipulation or lateral movement within sensitive backend infrastructure.\nThe vulnerability represents a failure in the application's authorization logic, where the backend fails to validate the user's permissions before processing connection requests to requested MCP resources.",
  "technicalDetails": "The root cause of this vulnerability is an authorization bypass within the /mcp-connect endpoint logic in obot versions prior to v0.21.1. The application fails to verify whether a user has the appropriate authorization privileges to access a specific MCP server instance before establishing a connection.\nWhen an authenticated user invokes the /mcp-connect endpoint, the server expects an MCP server ID as part of the request. Due to the lack of server-side Access Control Rule enforcement, the application treats the request as legitimate regardless of the user's restricted status or lack of explicit permission to the target resource.\nThe attack flow proceeds as follows: First, an attacker authenticates as a standard user within the obot environment. Second, the attacker identifies or guesses the target server ID for a restricted backend system. Third, the attacker initiates a request to /mcp-connect, supplying the target server ID. Fourth, the backend validates the authentication token but neglects to check the associated Access Control Rules, resulting in an established connection to the unauthorized MCP server.\nOnce the connection is established, the attacker gains the ability to leverage stored OAuth credentials associated with the obot environment. These credentials, which were intended to be used only within the scope of authorized operations, are now available for the attacker to perform arbitrary MCP tool calls.\nThis behavior allows the attacker to interact with, manipulate, or exfiltrate data from backend systems connected via the MCP protocol. Because the interaction happens through the application's established credentials, the actions may appear legitimate within the scope of the backend system's audit logs, complicating detection.\nThe vulnerability specifically affects the communication handling of the MCP integration module. The lack of granular authorization checks at the endpoint level effectively nullifies the protection offered by Access Control Rules, granting unauthorized users the same capabilities as a fully privileged user regarding the target MCP resource."
}