NextCRM CVE-2026-47129

The attacker must hold any authenticated NextCRM session - even the lowest 'member' or 'viewer' role suffices; no admin role or additional configuration is needed because the activateUser/deactivateUser Server Actions perform no role check at all (PR:L). What limits exploitation: the attacker cannot be fully anonymous (a valid login is required, so deployments that disable self-registration and tightly control account issuance shrink the attacker pool), and the impact is confined to flipping accounts' active/inactive state (integrity/availability) rather than reading or exfiltrating CRM data. Any NextCRM instance before 0.12.0 that provisions non-admin user accounts is exposed in its default configuration.

The CVSS 3.1 base score is 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H): network-reachable, low complexity, requires only low privileges (any authenticated account), no user interaction, with high integrity and availability impact but no confidentiality impact. The realistic risk is meaningful for any multi-tenant or multi-user NextCRM deployment because the barrier is merely a valid member/viewer login, and the impact - deactivating the primary administrator - is a direct, easily-triggered denial of service against privileged accounts. No EPSS score, KEV listing, or POC was provided, so this is not confirmed as actively exploited and appears to be a disclosed-and-patched issue rather than a widespread campaign. The signals are internally consistent (network vector matches HTTP-invocable Server Actions; low-privilege requirement matches 'any authenticated user'), so no metric conflict needs vendor verification. The main caveat is that C:N understates nothing here - this is an integrity/availability flaw, not data theft, so prioritization should weigh account-takeover-of-availability rather than data-breach risk.

A disgruntled employee or a compromised low-privilege account holder (member or viewer) in a shared NextCRM instance directly invokes the deactivateUser Server Action against the main administrator's user ID using nothing more than their normal session cookie. The admin is instantly locked out, and the attacker can additionally deactivate other staff to disrupt operations or reactivate previously disabled accounts. No public POC is required - the attack is a single authenticated HTTP call given low complexity (AC:L) and no user interaction.