Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-10-11T13:17:19.230Z",
  "pubdate": "2026-10-11T13:17:19.230Z",
  "executiveSummary": "Vearch versions 3.5.2 through 3.5.9 are susceptible to an incorrect authorization vulnerability located within the Role.HasPermissionForResources function.\nThe vulnerability arises from a failure to correctly enforce ReadOnly or None privilege levels for specific resources associated with a defined role.\nThis flaw allows authenticated non-root users to perform unauthorized write operations, such as document upserts and deletions, despite having restricted read-only permissions.\nFurthermore, the vulnerability enables privilege escalation, as attackers can invoke the PUT /roles endpoint to modify their own role privileges to WriteRead, ultimately facilitating cluster administrator access.\nThe security risk is high, as it breaks the principle of least privilege, bypasses resource-level access controls, and permits full administrative takeover by standard authenticated users.\nExploitation requires the attacker to hold an existing authenticated session within the cluster, at which point they can leverage the logic flaw to manipulate cluster state and resource permissions.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the Role.HasPermissionForResources function, which governs the authorization logic for resource access within the Vearch framework.\nDuring the verification process, the function fails to adequately evaluate the designated privilege levels—specifically ReadOnly and None—assigned to resources within a role's configuration.\nBecause the logic fails to enforce these restrictions, the system erroneously validates requests for operations that should be prohibited, treating them as authorized requests despite the lack of requisite permissions.\nThe exploitation flow begins with an authenticated non-root user identifying the target resource. When the user attempts to perform sensitive actions—such as document upserts or deletions—the faulty Role.HasPermissionForResources function validates the request as permitted, effectively bypassing the expected authorization check.\nBeyond unauthorized data manipulation, an attacker can exploit this oversight to achieve vertical privilege escalation.\nBy interacting with the PUT /roles API endpoint, the user can redefine the privileges associated with their own role. Because the underlying security logic fails to validate the current user's authorization to modify role definitions effectively, the attacker can promote their role to include WriteRead permissions.\nGranting these elevated privileges allows the attacker to gain full control over the cluster, effectively attaining administrative-level permissions.\nThis behavior exposes the cluster to significant integrity and availability risks, as an attacker can modify cluster metadata, delete index data, or manipulate administrative settings without prior elevated privileges.\nThe vulnerability affects all Vearch deployments utilizing versions 3.5.2 through 3.5.9. As the issue exists within the core authorization logic of the API request handling flow, it is inherent to the application architecture across these versions.\nNo external network access is required beyond the ability to authenticate to the Vearch API, making this a critical vulnerability for multi-tenant or shared-access Vearch instances where role-based access control (RBAC) is the primary line of defense."
}