Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as granted basic user
-
ExploitRequest GET /api/all-mcps/entries/{entry_id}
-
ExecutionRead plaintext static API keys/tokens
-
ImpactAbuse credentials against backend services
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V6 - Authentication Credential protection in transit/storage
|
| Exploitation Conditions | Exploitation requires an authenticated Obot account at 'basic' privilege (CVSS PR:L) that has been explicitly granted the target MCP catalog entry through Obot's access-control rules, AND the catalog entry must have static secret values (API keys/tokens) set on it by an admin or power user. Given those conditions, the attacker simply calls GET /api/all-mcps/entries/{entry_id} and the static configuration is returned in plaintext. Limiting factors that reduce real-world risk: valid authentication is mandatory (no anonymous access), the attacker must have been granted the specific entry, and only entries that actually carry admin-set static secrets are exploitable - entries using user-supplied config or Kubernetes secret bindings are not affected. The fix is deployed by upgrading to Obot v0.26.2 or later. |
| Impact | This is a genuine but moderate-priority issue, not an inflated high-CVSS finding. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) scores 7.1 and is internally consistent with the description: network-reachable, low complexity, requiring low privileges (PR:L = an authenticated 'basic' user), no user interaction, with high confidentiality impact and no integrity or availability impact. That maps cleanly to a read-only credential-disclosure flaw (CWE-522). No EPSS score was provided, the CVE is NOT on CISA KEV, and no public exploit code was referenced, so exploitation status is: no public exploit identified at time of analysis. The practical risk is bounded by a real precondition - the attacker must already be an authenticated user who has been granted a specific MCP catalog entry via access-control rules, and that entry must contain static secrets configured by an admin or power user - so this is privilege-escalation-of-data by an insider or a compromised low-privilege account rather than remote unauthenticated takeover. The secondary impact is notable: leaked API keys/tokens can be abused against external backend services, extending blast radius beyond Obot itself, which is why the confidentiality rating is appropriately High. A patch is confirmed available (release v0.26.2; commit 644a1fd), and VulnCheck is the reporting source with a dedicated advisory, raising confidence in the finding's validity. |
| Exploit ScenarioDerived | A legitimate low-privilege ('basic') Obot user who has been granted access to an MCP catalog entry issues a GET /api/all-mcps/entries/{entry_id} request and receives the entry manifest with static configuration values returned in plaintext, including API keys or tokens that an admin embedded. The user then replays those credentials directly against the upstream backend services they authenticate to. No public exploit code was identified, but the attack requires only a routine authenticated API call and no special tooling. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Obot versions 0.12.0 through 0.26.1 return admin- and power-user-supplied static secrets (API keys, tokens) on MCP catalog entries in plaintext to any user who has been granted that entry through Obot's access-control rules, exposing credentials for abuse against backend services. Affected users need a valid Obot account at basic privilege plus an explicit grant on the target entry, and the entry must actually carry admin-set static configuration values, so anonymous exploitation is not possible and only a subset of catalog entries is reachable in practice; the assessed severity is moderate (CVSS 7.1, confidentiality-only impact with no integrity or availability loss). No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (no CISA KEV listing); the vendor has released a fix in Obot v0.26.2.
RemediationAI
Vendor-released patch: Obot v0.26.2. Upgrade to v0.26.2 or later; the fix is delivered by commit 644a1fd60a66125ced3de10b350a983e933def7a and detailed in GHSA-q5wf-87f5-cxgq and the v0.26.2 release notes. Because secrets in affected entries were stored in the manifest itself, treat every static API key or token configured on an MCP catalog entry under a vulnerable version as compromised and rotate it at the upstream backend service after upgrading. If immediate upgrade is not possible, the actionable compensating controls are: remove static values from affected catalog entries and force user-supplied configuration instead (users then supply their own credentials, at the cost of losing the shared-service convenience), or migrate static secrets to Kubernetes secret bindings, which keeps the value out of the entry manifest; additionally narrow Obot's access-control rules so that only trusted admin or power-user accounts are granted entries that carry static secrets, accepting that this reduces the reach of the catalog. Note that the patched code adds an admin-restricted POST /api/workspaces/{workspace_id}/entries/{entry_id}/reveal endpoint, so any intentional disclosure of a static value after upgrading must go through that endpoint rather than the standard entry read. Rotating exposed credentials is required regardless of the mitigation chosen, since disclosure cannot be undone retroactively.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Obot is a Go-based platform for cataloging and serving Model Context Protocol (MCP) servers, where catalog entries describe an MCP server along with its configuration fields. Configuration fields can be supplied by the end user at connection time or set statically by an admin/power user; prior to the fix, static values were persisted directly inside the entry manifest, which meant the same manifest served by GET /api/all-mcps/entries/{entry_id} also carried the plaintext secret. This is a classic CWE-522 (Insufficiently Protected Credentials) failure: the credential is stored in a queryable object rather than an encrypted credential store, so the authorization model effectively leaks it to anyone the entry's read permission is granted to. The upstream fix (commit 644a1fd60a66125ced3de10b350a983e933def7a) introduces a StaticConfigurationRevision field that points the entry at a value held in Obot's encrypted credential store, adds a Static boolean to MCPConfig to mark such fields, strips the raw value out of the returned catalog-entry manifest, and adjusts the required-configuration validation logic so that fields backed by stored static credentials are no longer treated as missing. It also adds a dedicated, more tightly restricted POST /api/workspaces/{workspace_id}/entries/{entry_id}/reveal route so that disclosure of a static value is an explicit, separately authorized action rather than a side effect of reading the entry.
Know when Obot gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Network-reachable API read requiring an authenticated granted basic user (PR:L), no interaction; discloses plaintext credentials so C:H, with no integrity or availability impact and no scope change in the vulnerable component.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
Obot 0.12.0 before 0.26.2 contains an insufficiently protected credentials vulnerability that allows authenticated users to read static secrets set on MCP catalog entries by admins or power users. Basic users granted an entry by access control rules can request GET /api/all-mcps/entries/{entry_id} to obtain plaintext API keys or tokens and abuse them against backend services.
Technical POC Analysis
CWE-522 (Insufficiently Protected Credentials).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Obot deployments on versions 0.12.0 through 0.26.1 can disclose administrator-configured static credentials - API keys and tokens used to reach backend services - in plaintext to users who already hold an access grant on the affected MCP catalog entries. The exposure is limited to authenticated account holders with explicit permissions and does not affect availability or data integrity, but any leaked credential carries whatever backend privileges it was issued with, so risk concentrates in environments where catalog entries embed high-privilege secrets. Leadership should care because remediation is a low-effort version upgrade, while inaction leaves reusable credentials in the hands of a broad internal audience.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Obot deployments started with the README's Docker quickstart expose port 0.0.0.0:8080 with authentication disabled, allo
Authorization bypass in Obot before v0.21.1 lets any authenticated user with a known MCP Server ID connect to restricted
OAuth dynamic client registration in Obot through v0.22.1 allows unauthenticated remote attackers to register an OAuth c
An authorization bypass in Obot 0.21.1 through 0.24.1 lets any authenticated account holding the low-privileged 'Basic-r
Server-side request forgery in Obot through v0.22.1 allows an authenticated user holding the Power User, Power User Plus
Unauthenticated disclosure of MCP Registry metadata affects Obot deployments running versions up to and including v0.22.
Authorization bypass in Obot 0.26.0 through 0.26.1 lets an authenticated user who matches any configured vMCP (virtual M
Obot versions 0.25.0 through 0.25.5 and 0.26.0 can persist stale group memberships after an administrator revokes a user
EUVD-2026-94309
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB