Vearch EUVD-2026-96911

Exploitation requires an existing authenticated non-root Vearch account (PR:L) that has been assigned a role whose resources carry ReadOnly or None privilege levels; the flaw is that Role.HasPermissionForResources ignores those stored levels, so the account can perform write operations (document upsert/delete) and invoke the PUT /roles endpoint to self-escalate to WriteRead. The specific product features involved are Vearch's RBAC role-permission evaluation and the /roles management API. Limiting factors: the attacker must already possess valid credentials for a low-privilege account (no anonymous/unauthenticated path), and only versions 3.5.2 through 3.5.9 are affected - environments with no untrusted low-privileged users or multi-tenant exposure face substantially reduced real-world risk.

This is a genuine, actionable priority rather than a high-CVSS-but-low-real-risk issue, though the exploitation surface is gated by authentication. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) reports a network-reachable, low-complexity flaw requiring only low privileges (PR:L) and no user interaction, with high confidentiality, integrity, and availability impact on the vulnerable system - consistent with CWE-863 (Incorrect Authorization). The description corroborates the vector precisely: any already-authenticated non-root user can bypass stored ReadOnly/None privilege checks, meaning the realistic attacker is an existing low-privileged account (insider, compromised credential, or multi-tenant user) rather than an anonymous internet attacker. EPSS is not provided in the input, so exploitation probability cannot be quantified. KEV status is not indicated (treat as not listed), and no POC flag is provided, so there is no public exploit identified at time of analysis - however, the referenced HackMD write-up and the pinpoint links to the vulnerable Go source (user.go:300-313 and role_service.go:180-229) provide a clear reproduction path that materially lowers the bar to independent exploit development. Signals are consistent (no conflicts between vector and description), but the key missing data is EPSS and any confirmed in-the-wild activity; the decisive risk factor is whether low-privileged accounts are exposed to untrusted users.

A low-privileged authenticated Vearch user who was granted only ReadOnly access to a resource issues upsert/delete operations against documents they should not be able to modify, because Role.HasPermissionForResources ignores the stored ReadOnly/None level. The same user then calls PUT /roles to grant their own role WriteRead privileges, escalating step-by-step toward cluster administrator control. No public exploit is identified at time of analysis, but a detailed vendor/researcher write-up and direct source-code references make reproduction straightforward.