CVE-2026-108746 in Vearch
Summary
by MITRE • 10/11/2026
Vearch 3.5.2 through 3.5.9 contains an incorrect authorization vulnerability in Role.HasPermissionForResources that ignores stored ReadOnly or None privilege levels for resources listed in a role. Authenticated non-root users can upsert and delete documents with read-only access, or call PUT /roles to grant their role WriteRead privileges, escalating toward cluster administrator access.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in Vearch versions 3.5.2 through 3.5.9 represents a critical failure in the application's authorization logic, specifically within the Role.HasPermissionForResources function. This flaw allows authenticated users who do not possess root or administrative privileges to bypass intended access controls and perform actions that should be restricted by their assigned role permissions. The core of the issue lies in how the system evaluates resource-level privileges when determining whether a user has permission to execute specific operations. Instead of strictly enforcing the stored privilege levels, such as ReadOnly or None, for resources associated with a given role, the authorization mechanism fails to correctly validate these constraints before allowing write-related actions.
From a technical perspective, this defect enables authenticated non-root users to upsert and delete documents in collections where they are explicitly granted only read-only access. This means that data integrity is compromised as malicious actors can modify or remove critical information without proper authorization. Furthermore, the vulnerability extends beyond simple data manipulation; it allows attackers to escalate their privileges by calling the PUT /roles endpoint. By exploiting this API call, an attacker can grant their own role WriteRead privileges, effectively bypassing the principle of least privilege and gaining significantly higher levels of access than originally intended by the system administrators.
The operational impact of this vulnerability is severe, as it directly undermines the security posture of any deployment relying on Vearch for data management. The ability to delete or modify read-only resources can lead to significant data loss, corruption, or unavailability, disrupting business operations that depend on accurate and consistent data states. More critically, the potential for privilege escalation means that an attacker with low-level access can transform into a cluster administrator. This level of compromise allows full control over the database environment, including the ability to create new administrative accounts, modify system configurations, and potentially exfiltrate sensitive information stored within the clusters.
This vulnerability aligns with Common Weakness Enumeration (CWE) category CWE-269, which describes Improper Privilege Management, as well as CWE-862, Missing Authorization, because the application fails to enforce proper access controls for authorized users. In terms of the MITRE ATT&CK framework, this behavior is indicative of T1078 Valid Accounts and potentially T1068 Exploitation for Privilege Escalation, where an attacker leverages valid credentials to gain higher-level permissions that were not explicitly granted during initial authentication or role assignment.
To mitigate this risk, organizations running Vearch versions 3.5.2 through 3.5.9 should immediately upgrade to a patched version of the software where the authorization logic in Role.HasPermissionForResources has been corrected to strictly enforce stored privilege levels. Until an update is applied, administrators can implement compensating controls such as restricting network access to the Vearch API endpoints using firewalls or reverse proxies that validate user roles before forwarding requests. Additionally, enabling comprehensive audit logging for all role modification and data mutation events will help in detecting any unauthorized attempts to exploit this vulnerability. Regular review of assigned permissions and adherence to strict least-privilege principles are essential practices to minimize the attack surface associated with such authorization flaws.