CVE-2026-79786 in Coroot
Summary
by MITRE • 08/25/2026
Coroot's unauthenticated MCP OAuth dynamic client registration endpoint accepts any syntactically valid redirect URI without validation, allowing attackers to register clients pointing to attacker-controlled hosts. Attackers can send authorization URLs to signed-in users, capture their authorization codes upon consent approval, and exchange them for access tokens to hijack MCP sessions.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in Coroot stems from a critical failure in the implementation of the OAuth 2.0 dynamic client registration mechanism, specifically within its Model Context Protocol (MCP) integration layer. This endpoint is designed to allow applications to register themselves as authorized clients without requiring pre-existing administrative configuration, which inherently increases the attack surface if not strictly controlled. The core technical flaw lies in the absence of rigorous validation for redirect URIs during this dynamic registration process. While the system correctly ensures that submitted URI strings are syntactically valid according to standard URL parsing rules, it fails to enforce any policy-based restrictions on the domain or host component of these URIs. This oversight allows an unauthenticated attacker to register a malicious client by specifying a redirect URI that points to a server under their direct control. By bypassing checks such as allow-lists for trusted domains or requiring administrative approval for new registrations, the system effectively permits any external entity to become a legitimate OAuth client within the Coroot environment.
The operational impact of this flaw is severe and directly facilitates account takeover through session hijacking. Once an attacker has successfully registered their malicious client with a redirect URI pointing to their own infrastructure, they can initiate a standard OAuth authorization flow against targeted users who are already authenticated in the Coroot platform. The attacker constructs a specially crafted authorization URL that references their newly registered client ID and specifies their controlled domain as the destination for the response code. When an unsuspecting user clicks this link or is tricked into visiting it, they are presented with the standard consent screen asking to authorize the malicious application's access permissions. If the user approves this request, the Coroot server generates an authorization code and redirects the browser back to the attacker-controlled URI, appending the sensitive code as a query parameter. The attacker then intercepts this redirect by capturing the URL from their web server logs or through other means of monitoring incoming traffic.
With possession of the valid authorization code, the attacker proceeds to the final stage of the OAuth flow by exchanging it for an access token at Coroot's token endpoint. Since the registration was performed legitimately according to the system's flawed logic, and the redirect URI matches exactly what was registered, the server issues a valid access token without raising any security flags or requiring additional multi-factor authentication steps beyond the initial user consent. This access token grants the attacker full privileges associated with the hijacked session, allowing them to impersonate the victim within the Coroot platform. Depending on the permissions granted during the consent phase and the default scopes of the MCP integration, this could lead to unauthorized viewing of sensitive operational data, modification of configurations, or potentially deeper lateral movement if the access token can be used to authenticate against other backend services integrated with Coroot. This type of attack is particularly dangerous because it relies on social engineering tactics rather than exploiting a complex code execution flaw, making it difficult for traditional intrusion detection systems to identify without specific behavioral analytics focused on OAuth flows.
From a classification perspective, this vulnerability aligns closely with CWE-287, which describes Improper Authentication, specifically in the context of misconfigured identity verification mechanisms where the system fails to verify that the requesting entity is authorized to perform certain actions or access resources. Furthermore, it maps directly to MITRE ATT&CK technique T1528, Steal Application Access Token, as well as aspects of T1078, Valid Accounts, since the attacker leverages legitimate credentials obtained through deception. The root cause also reflects CWE-601, URL Redirection to Untrusted Site, highlighting the failure to validate that redirection targets are safe and authorized by the application owner. To mitigate this risk, immediate remediation should focus on implementing strict allow-listing for redirect URIs during dynamic client registration, ensuring that only pre-approved domains can be registered as clients. Additionally, requiring administrative approval or multi-factor authentication for new client registrations would significantly raise the barrier for attackers. Implementing PKCE (Proof Key for Code Exchange) is also essential to prevent authorization code interception attacks even if a valid redirect URI were somehow compromised. Long-term strategies should include regular security audits of OAuth implementations and adopting zero-trust principles where every request, including token exchanges, must be rigorously validated against established trust boundaries.