CVE-2026-121558 in intelligent-audit-system
Summary
by MITRE • 11/03/2026
AuditPilot before commit 4669c93 contains an authorization bypass vulnerability in _metadata_allowed in rag/agentic_rag.py that allows authenticated users to read other projects' knowledge by supplying project_id. Attackers with read:knowledge scoped to one project can set context.project_id via GET /api/knowledge/query or POST /api/research/answer to retrieve same-tenant project knowledge chunks.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in AuditPilot prior to commit 4669c93 represents a critical authorization bypass within the application's agentic retrieval-augmented generation module. Specifically, the flaw resides in the _metadata_allowed function located in rag/agentic_rag.py. This component is responsible for validating whether an authenticated user has permission to access specific knowledge bases or project data. The core technical failure involves improper enforcement of object-level authorization controls, where the system relies on a client-supplied parameter rather than server-side validation of the user's actual permissions relative to the requested resource.
In this scenario, the application accepts a project_id input via GET /api/knowledge/query and POST /api/research/answer endpoints. The vulnerability allows an attacker who is authenticated with read:knowledge scope for one specific project to manipulate the context.project_id field in their request payload or query parameters. By supplying a different project_id that belongs to another tenant or distinct project within the same system, the application fails to verify if the requesting user has explicit access rights to that target project. Consequently, the authorization check is bypassed because the _metadata_allowed function does not adequately cross-reference the provided project identifier against the authenticated session's permitted scopes.
The operational impact of this vulnerability is severe, as it leads to a complete breach of data confidentiality across multi-tenant boundaries or between isolated projects within the same organization. Attackers can retrieve sensitive knowledge chunks, documents, and contextual information belonging to other users or departments. This exposure violates the principle of least privilege and undermines the isolation mechanisms intended to protect proprietary or confidential information. The ability to read arbitrary project data via standard API endpoints means that any authenticated user with minimal permissions can escalate their access to view restricted content without needing elevated privileges or exploiting additional flaws in authentication logic.
This vulnerability aligns directly with CWE-284, which describes Improper Access Control, specifically reflecting a failure to enforce proper restrictions on authorized individuals regarding specific objects. From an offensive security perspective, this behavior is characteristic of ATT&CK technique T1078, Valid Accounts, where attackers leverage existing credentials to access resources they are not explicitly permitted to view. The exploitation vector involves manipulating input parameters in API calls, which corresponds to common patterns seen in broken object level authorization flaws often categorized under CWE-639 when context is improperly managed within the application logic.
To mitigate this vulnerability, it is essential to enforce strict server-side validation of resource ownership and access rights for every request involving sensitive data retrieval. The _metadata_allowed function must be updated to verify that the authenticated user's session explicitly includes permissions for the specific project_id being requested, rather than trusting the value provided in the client input. Implementing robust identity and access management checks at the API layer ensures that users can only interact with resources they are authorized to access. Additionally, applying principle of least privilege by restricting read:knowledge scopes to strictly defined resource identifiers will prevent lateral movement between projects. Upgrading AuditPilot to a version after commit 4669c93 resolves this issue as it includes the necessary patches for proper authorization enforcement in the agentic RAG module.