Liberu CRM CVE-2026-61519

Exploitation requires the attacker to already hold a valid pending team invitation for a target team (PR:L) - this is the gating precondition, so it is not exploitable by a fully anonymous outsider. Given that, the attacker sends a POST to the team-invitations route specifying the 'admin' role for a second attacker-controlled account; the flawed authorization predicate in TeamPolicy::addTeamMember() grants the invite right solely on a pending-invitation email match, and InviteTeamMember does not enforce privilege-level validation. No victim interaction is needed beyond the attacker's own second account accepting the invitation. Affected versions are Liberu CRM 0.9.1 through those before 10.0.0; upgrading to v10.0.0 removes the flaw.

The CVSS 4.0 score of 8.7 (High) reflects a network-reachable (AV:N), low-complexity (AC:L), low-privilege (PR:L) broken-access-control flaw with high confidentiality, integrity, and availability impact on the vulnerable system (VC:H/VI:H/VA:H), no scope change to other systems (SC/SI/SA:N). The signals are internally consistent: PR:L correctly reflects that the attacker must already hold a pending team invitation (a low but non-zero privilege), and UI:N reflects that the elevation itself needs no victim action beyond the attacker-controlled second account accepting. No EPSS score, KEV listing, or public POC was supplied, so this is 'no public exploit identified at time of analysis' - the risk is credible on paper but there is no evidence of active or automated exploitation. The real-world priority is tempered chiefly by prevalence: Liberu CRM is a niche open-source Laravel application, not enterprise-ubiquitous software, so blast radius is limited to the relatively small population that deploys it. Within a deployed instance, however, the flaw is serious - it yields full admin-level CRUD over all team-scoped data. No conflicting signals: the description (specific POST to team-invitations route, low-privilege invitee) matches the CVSS vector well.

An attacker who has been sent (or otherwise obtained) a pending team invitation crafts a POST request to the team-invitations route naming a second, attacker-controlled account and specifying the 'admin' role. Because TeamPolicy::addTeamMember() authorizes the action based only on the existence of a matching pending-invitation email - and InviteTeamMember fails to validate the requested privilege level - the second account is attached to the team with full admin rights upon acceptance. No public POC is referenced, but the described request is trivial to reproduce.