Description

ChatCLI before v1.215.2 contains an improper validation vulnerability in the MCP OAuth login flow that uses server-supplied Protected Resource Metadata as the resource indicator without checking it matches the configured server URL. A malicious MCP server can declare another resource on the same authorization server, obtain the user's bearer token for it, and replay that token against the other resource.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.0",
  "pubDate": "2026-11-05T19:17:20.543Z",
  "pubdate": "2026-11-05T19:17:20.543Z",
  "executiveSummary": "ChatCLI versions prior to v1.215.2 are susceptible to an improper validation vulnerability within the MCP OAuth login flow.\nThe vulnerability stems from the client's failure to verify that the Protected Resource Metadata, supplied by the MCP server, corresponds to the pre-configured authorized server URL.\nThis flaw enables a malicious MCP server to conduct cross-resource token redirection attacks by manipulating the resource indicator during the authorization flow.\nAn attacker can induce the client to authenticate against a legitimate authorization server while requesting a scope or resource audience controlled or targeted by the attacker.\nUpon successful authorization, the client receives a bearer token intended for the attacker-specified resource, which can then be exfiltrated or replayed against that resource by the malicious server.\nThe vulnerability poses significant security risks to user identity and data integrity, as it facilitates unauthorized access to secondary resources under the guise of an authenticated user session.\nExploitation requires the user to interact with a compromised or malicious MCP server, granting the attacker the ability to intercept tokens authorized for other protected resources.",
  "technicalDetails": "The core of this vulnerability lies in the improper handling of Protected Resource Metadata during the MCP OAuth protocol exchange. Specifically, the client implementation fails to perform strict validation checks between the server-supplied resource indicator and the statically configured, expected resource URL.\nIn the MCP OAuth flow, the client relies on metadata provided by the MCP server to define the target resource for the requested access token. By omitting a cross-reference check against the trusted server configuration, ChatCLI allows the server to inject arbitrary resource indicators.\nThe attack flow proceeds as follows: First, a user connects to a malicious MCP server, which initiates an OAuth authorization request. The malicious server provides a crafted Protected Resource Metadata payload specifying a target resource (e.g., a secondary API or service) that resides on the same authorization server but is different from the intended MCP server resource.\nBecause ChatCLI does not validate this metadata against the legitimate MCP server configuration, it includes this attacker-provided resource indicator in the authorization request directed toward the authorization server.\nUpon successful user authentication, the authorization server issues a bearer token valid for the resource specified in the request—in this case, the attacker's chosen target. The authorization server returns this token to the ChatCLI client, which then presents it back to the MCP server as part of the handshake completion.\nThe malicious MCP server, now in possession of a valid bearer token for the secondary resource, can replay this token to access restricted data or perform actions on the user's behalf within that secondary resource context.\nThe vulnerability is present in the OAuth flow processing logic within ChatCLI versions prior to v1.215.2. It effectively bypasses the principle of least privilege, as the token obtained is intended for a resource context that the user did not explicitly intend to authorize within the scope of the MCP session.\nThere are no requirements for elevated privileges on the client side, as the flaw resides in the protocol implementation logic itself. Network exposure is limited to the communication path between the client and the malicious MCP server, which then interacts with the common authorization server to finalize the exploit chain."
}