Coroot CVE-2026-79786

The primary prerequisite is that Coroot's MCP OAuth feature is enabled and the dynamic client registration endpoint is network-reachable by the attacker - deployments that firewall this endpoint to internal networks only are not exploitable externally. The attack additionally requires a signed-in Coroot user to receive, click, and actively approve a consent dialog on a crafted authorization URL; the attacker cannot complete exploitation passively. The CVSS vector PR:N confirms registration itself is unauthenticated, but the consent step requires an already-authenticated Coroot user. Coroot instances that have MCP OAuth disabled or restrict the registration endpoint to trusted clients are not exposed to this attack path. No non-default configuration beyond MCP OAuth availability is required for the registration step - if the feature is on and network-accessible, the registration requires no credentials.

The CVSS 4.0 score of 7.0 (AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:L/VA:N) correctly reflects the central tension: registration is fully unauthenticated and low-complexity, but end-to-end exploitation requires a signed-in user to click a crafted link and actively approve an OAuth consent prompt - a meaningful friction point that prevents fully automated mass exploitation. No EPSS data was supplied, and the absence of a CISA KEV listing indicates no confirmed widespread exploitation at time of analysis. The attack is not automatable end-to-end due to the required active user interaction (UI:A), which limits scalable abuse compared to purely server-side flaws. Organizations with Coroot MCP OAuth exposed to untrusted networks should treat this as a medium-high priority given the direct path to session hijacking, while deployments with the registration endpoint firewalled internally face substantially lower realistic risk. The confidentiality impact is high - a captured access token grants the attacker ongoing authenticated access to the victim's Coroot MCP session.

An attacker sends a POST request to Coroot's unauthenticated dynamic client registration endpoint, registering a new OAuth client with a redirect URI pointing to an attacker-controlled server. The attacker then crafts a valid authorization URL referencing this client ID and delivers it (via phishing, chat message, or embedded link) to a user who is actively signed into Coroot. When the user follows the link and approves the consent dialog, the authorization server issues a code to the attacker's redirect URI rather than a legitimate client endpoint. The attacker exchanges that code for a valid access token and uses it to make authenticated API calls to the victim's Coroot MCP session. No public exploit code has been identified at time of analysis, though the attack requires only standard HTTP requests.