EUVD-2026-41424
GHSA-667j-56pf-pq9c
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network API reachable with low complexity, but requires an authenticated account holding delegated assign/revoke permission (PR:L); resulting admin takeover yields full C/I/A impact within the same database authority (S:U).
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
Weaviate before 1.38.0 does not verify that a principal performing an RBAC role assignment holds the permissions granted by the assigned role. The assignRoleToUser and assignRoleToGroup handlers (POST /authz/users/{id}/assign and /authz/groups/{id}/assign) authorize only that the caller may assign roles to the target user or group, not the permissions contained in the assigned roles, unlike role creation which enforces that a user can only create roles with permissions less than or equal to its own. A user holding only the delegated assign_and_revoke_users or assign_and_revoke_groups permission can assign the built-in admin role, or any high-privilege custom role, to itself or others, escalating to full administrative control of the database.
AnalysisAI
Privilege escalation in Weaviate vector database versions before 1.38.0 allows a user holding only the delegated assign_and_revoke_users or assign_and_revoke_groups permission to grant the built-in admin role (or any high-privilege custom role) to itself or others, obtaining full administrative control of the database. The flaw stems from the role-assignment handlers checking only that the caller may assign roles to a target, but never verifying the caller actually holds the permissions being conferred - unlike role creation, which enforces permission subset checks. Reported by VulnCheck with a vendor patch in v1.38.0; no public exploit identified at time of analysis.
Technical ContextAI
Weaviate is an open-source AI-native vector database that ships a role-based access control (RBAC) authorization layer. The vulnerability lives in the assignRoleToUser and assignRoleToGroup handlers, exposed via POST /authz/users/{id}/assign and POST /authz/groups/{id}/assign. These endpoints enforce authorization only on the 'can this caller assign roles to this target' axis and omit the 'does this caller already possess the permissions inside the role being assigned' check. This is a textbook CWE-266 (Incorrect Privilege Assignment): the delegated assignment capability is treated as sufficient authority to grant arbitrary privilege bundles. Weaviate's role-creation path correctly enforces that a principal may only create roles whose permissions are a subset of its own, so the assignment path represents an inconsistent, weaker security boundary for the same effective privilege-granting operation. The single affected CPE is cpe:2.3:a:weaviate:weaviate:*:*:*:*:*:*:*:* covering all versions prior to 1.38.0.
RemediationAI
Vendor-released patch: upgrade to Weaviate v1.38.0 or later (https://github.com/weaviate/weaviate/releases/tag/v1.38.0), which adds the missing check so a principal can only assign roles whose permissions are a subset of its own; the corresponding fix is in PR 11493 and commit 2c75f6fb217631f7751c4b2a7d37a488cef13edb. If immediate upgrade is not possible, the most effective compensating control is to revoke the assign_and_revoke_users and assign_and_revoke_groups permissions from all non-admin principals and centralize role assignment with fully trusted admin accounts - the trade-off is loss of delegated user/group administration until patched. Additionally, restrict network access to the /authz/users/{id}/assign and /authz/groups/{id}/assign endpoints to trusted management hosts, and audit existing role bindings for any unexpected assignment of the built-in admin role or high-privilege custom roles. Reference the VulnCheck advisory (https://www.vulncheck.com/advisories/weaviate-privilege-escalation-via-unchecked-permissions-in-rbac-role-assignment) for detection guidance.
An issue in weaviate v.1.20.0 allows a remote attacker to cause a denial of service via the handleUnbatchedGraphQLReques
Server-side request forgery in Weaviate's Verba (GoldenVerba) RAG application version 2.1.3 lets unauthenticated remote
Authorization bypass in Weaviate's Static API Key Handler (versions 1.37.0-1.37.7) stems from the validateConfig functio
Same weakness CWE-266 – Incorrect Privilege Assignment
View allSame technique Privilege Escalation
View allShare
External POC / Exploit Code
Leaving vuln.today