Rapyd Admin EUVD-2026-97890

Exploitation requires an authenticated account that already holds the 'edit users' permission - the shipped 'operator' role is sufficient - and access to the UsersEdit Livewire component's user-edit form; the attacker submits the admin role ID for their own account and the pre-9.20.0 server synced browser-supplied roles without validating them against assignable roles. Limiting factors: the attacker must first obtain such a delegated role (not reachable by anonymous or self-registered customer users in the UsersEdit path), and the issue is fixed in v9.20.0, where assignable roles are computed server-side and a non-super-admin can no longer add a role to itself. This is an insider/compromised-privileged-account escalation, not a default-configuration unauthenticated flaw.

This is a genuine but access-gated privilege escalation (CWE-269) in an open-source Laravel admin scaffolding package. The strongest signals are CONFIRMED and internally consistent: the vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N, VC:H/VI:H/VA:H, score 8.6) aligns with the description - a network-reachable, low-complexity attack that nonetheless requires the attacker to already hold a role carrying the 'edit users' permission (e.g. the shipped operator role), so it is NOT unauthenticated. The high impact (full admin takeover, tenant-scoping bypass, per-record authorization bypass, impersonation) is corroborated by the vendor advisory and the fix commit, which show the client-supplied role list was synced verbatim. Key risk-dampening signals are MISSING rather than conflicting: no EPSS score was provided, there is no CISA KEV listing, and no public proof-of-concept exploit was supplied (the GitHub links are the patch/source, not weaponized exploit code). Net assessment: real and worth prioritizing for anyone running Rapyd Admin 9.0.0-9.19.x with delegated user-management roles, but the PR:H prerequisite means it is an insider/compromised-operator escalation vector, not a mass-exploitable internet-facing bug - tempering the 8.6 base score in most deployments.

A tenant operator (or any user granted the 'edit users' permission) opens the UsersEdit screen for their own account and submits the admin role ID in the role field, which the server synced without server-side validation. They instantly become super admin, escaping their tenant boundary and gaining the ability to impersonate and administer every account across all tenants. No public exploit code was supplied, but the vulnerable source lines and fixing commit are published, lowering the bar to reproduce.