GHSA-XWMW-PRC4-V3CR
Vulnerability from github – Published: 2026-09-18 17:59 – Updated: 2026-09-18 17:59Summary
In affected versions, an unauthenticated attacker could register an OAuth client with an arbitrary external redirect URI, and the authorization flow would auto-complete without a consent screen. If a logged-in victim visited a crafted authorization URL, an authorization code was delivered to the attacker's redirect URI and exchanged for an access token. That token was minted with the victim's full set of groups, so it could be used as a bearer token against the Obot API endpoints the victim had access to — rather than being scoped to just the requested MCP server.
Am I affected?
You are affected if you run Obot <= v0.22.1 with OBOT_SERVER_ENABLE_AUTHENTICATION=true. Exploitation requires a logged-in victim to visit a single attacker-controlled authorization URL.
Details
Three issues combined to create this vulnerability. First, OAuth dynamic client registration was reachable without authentication and applied no restriction on the redirect URIs a client could register, so an attacker could register a client pointing at their own domain. The authorization flow then auto-completed for an already-logged-in user with no consent step, so simply loading the authorization URL issued an authorization code and redirected it to the attacker's URI. Finally, the token minted by the MCP OAuth flow carried the victim's full group set in the JWT — the field used to authorize API paths — so although the token's audience was the requested MCP server, it was accepted across the victim's wider API access. (Obot's JWT verification validated the issuer but not the audience; audiences were enforced at the MCP layer.)
Impact
Worst case is that an attacker who gets a logged-in victim to click a crafted link obtains an access token (and refresh token) usable against the API endpoints the victim is authorized for — reading or modifying the victim's resources until the token is revoked. No attacker-side privileges are required.
Mitigation
Upgrade to v0.23.0 or later, which adds three protections: a consent screen that shows the requesting client and the MCP server it wants access to before authorization completes; restriction of tokens minted by the MCP OAuth flow to only the MCP involved in the request, so they can no longer reach the user's wider API access; and audience validation as a fail-safe ensuring these tokens are only accepted for the MCP server they were issued for.
Severity
CVSS v3.1 Score: 8.8/10 (High) — CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Credits
The Obot team would like to thank @EQSTLab for responsibly disclosing this issue in accordance with our security policy.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/obot-platform/obot"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-18T17:59:35Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nIn affected versions, an unauthenticated attacker could register an OAuth client with an arbitrary external redirect URI, and the authorization flow would auto-complete without a consent screen. If a logged-in victim visited a crafted authorization URL, an authorization code was delivered to the attacker\u0027s redirect URI and exchanged for an access token. That token was minted with the victim\u0027s full set of groups, so it could be used as a bearer token against the Obot API endpoints the victim had access to \u2014 rather than being scoped to just the requested MCP server.\n\n## Am I affected?\n\nYou are affected if you run Obot `\u003c= v0.22.1` with `OBOT_SERVER_ENABLE_AUTHENTICATION=true`. Exploitation requires a logged-in victim to visit a single attacker-controlled authorization URL.\n\n## Details\n\nThree issues combined to create this vulnerability. First, OAuth dynamic client registration was reachable without authentication and applied no restriction on the redirect URIs a client could register, so an attacker could register a client pointing at their own domain. The authorization flow then auto-completed for an already-logged-in user with no consent step, so simply loading the authorization URL issued an authorization code and redirected it to the attacker\u0027s URI. Finally, the token minted by the MCP OAuth flow carried the victim\u0027s full group set in the JWT \u2014 the field used to authorize API paths \u2014 so although the token\u0027s audience was the requested MCP server, it was accepted across the victim\u0027s wider API access. (Obot\u0027s JWT verification validated the issuer but not the audience; audiences were enforced at the MCP layer.)\n\n## Impact\n\nWorst case is that an attacker who gets a logged-in victim to click a crafted link obtains an access token (and refresh token) usable against the API endpoints the victim is authorized for \u2014 reading or modifying the victim\u0027s resources until the token is revoked. No attacker-side privileges are required.\n\n## Mitigation\n\nUpgrade to **v0.23.0** or later, which adds three protections: a consent screen that shows the requesting client and the MCP server it wants access to before authorization completes; restriction of tokens minted by the MCP OAuth flow to only the MCP involved in the request, so they can no longer reach the user\u0027s wider API access; and audience validation as a fail-safe ensuring these tokens are only accepted for the MCP server they were issued for.\n\n## Severity\n\nCVSS v3.1 Score: **8.8/10 (High)** \u2014 `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H`\n\n## Credits\n\nThe Obot team would like to thank [@EQSTLab](https://github.com/EQSTLab) for responsibly disclosing this issue in accordance with our [security policy](https://github.com/obot-platform/obot/?tab=security-ov-file).",
"id": "GHSA-xwmw-prc4-v3cr",
"modified": "2026-09-18T17:59:35Z",
"published": "2026-09-18T17:59:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/obot-platform/obot/security/advisories/GHSA-xwmw-prc4-v3cr"
},
{
"type": "PACKAGE",
"url": "https://github.com/obot-platform/obot"
},
{
"type": "WEB",
"url": "https://github.com/obot-platform/obot/releases/tag/v0.23.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Obot: OAuth Dynamic Client Registration Enables API Token Theft via Audience Confusion"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.