CVE-2026-129157 in ragent
Summary
by MITRE • 11/13/2026
ragent 1.0.0 through 1.1.0 contains a missing authorization vulnerability in RagTraceController that allows any logged-in user to view all users' RAG traces. Attackers can page through /rag/traces/runs and related node endpoints to read other users' usernames, user ids, conversation ids, questions, and per-node execution details.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/13/2026
The vulnerability identified in Ragent versions 1.0.0 through 1.1.0 represents a critical failure in access control mechanisms within the application's trace monitoring subsystem. Specifically, the RagTraceController endpoint lacks proper authorization checks to verify whether the authenticated user requesting data has permission to view specific resources. This flaw allows any logged-in user to bypass intended restrictions and access sensitive information belonging to other users by interacting with the /rag/traces/runs API endpoint and related node-specific endpoints. The absence of these controls means that the application relies solely on authentication rather than authorization, a common misconfiguration in web applications where session validity is assumed to imply resource ownership or appropriate privilege levels for all actions performed within that session.
From a technical perspective, this vulnerability enables an attacker who has valid credentials for any user account to enumerate and retrieve detailed execution traces of other users' interactions with the Retrieval-Augmented Generation system. By paginating through the /rag/traces/runs endpoint, an adversary can systematically collect usernames, unique user identifiers, conversation identifiers, specific questions posed by victims, and granular per-node execution details. This level of access transforms a simple authentication bypass into a significant data exfiltration risk, as the retrieved information provides deep insight into how other users interact with the AI system, including their query patterns and potentially sensitive context provided during conversations. The ability to view node-level execution details further exposes internal processing logic which could be leveraged for more sophisticated attacks against the underlying infrastructure or model configuration.
The operational impact of this vulnerability is severe due to the sensitivity of the exposed data types. Usernames and user IDs facilitate targeted phishing campaigns or social engineering attacks by providing accurate identifiers associated with real individuals within an organization. Conversation IDs and specific questions reveal proprietary business logic, customer inquiries, or internal research topics that were intended to be private per session. Furthermore, exposure of per-node execution details may leak information about the system's architecture, such as which retrieval sources are being accessed or how prompts are structured, potentially aiding attackers in crafting more effective adversarial inputs against the AI model itself. This constitutes a direct violation of confidentiality requirements and can lead to regulatory non-compliance depending on the nature of the data involved, particularly if personal identifiable information is embedded within conversation histories.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in enforcing restrictions on actions performed by authenticated users. In terms of offensive security frameworks, this behavior maps directly to ATT&CK technique T1078 Valid Accounts, where an attacker uses legitimate credentials to access resources they are not authorized to view, and potentially T1539 Steal Web Session Cookie if the attack vector involves session hijacking prior to exploitation, though here it primarily relies on existing valid sessions. The exposure of internal execution details also touches upon CWE-200 Exposure of Sensitive Information to an Unauthorized Actor. To mitigate this issue, developers must implement strict object-level authorization checks within the RagTraceController methods. This involves verifying that the user ID associated with the current session matches the owner ID of the requested trace resource before returning any data. Additionally, implementing rate limiting on these endpoints can help prevent automated enumeration attacks while patches are being deployed. Organizations should also consider auditing other controller endpoints for similar authorization gaps to ensure comprehensive protection against horizontal privilege escalation and unauthorized data access.