OpenCATS EUVD-2026-104918

Requires an authenticated OpenCATS account with at least READ-level access (PR:L) and network reachability to the web interface; the attacker invokes the import module's revert/rollback action with a valid importID, which ImportUI::handleRequest() processes without verifying the user holds ACCESS_LEVEL_EDIT. Exploitation is limited by the need for valid (even if low-privilege) credentials, the pre-existence of prior data imports to roll back, and a vulnerable version before 0.10.0; no administrative rights, user interaction, or non-default configuration is needed, making it a straightforward privilege-abuse path for any low-trust account.

This is a genuine but moderate-severity authorization flaw, not a critical priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms a network-reachable, low-complexity attack requiring low privileges (PR:L) - consistent with the description's 'low-privileged authenticated users' with READ-level access, so this is an insider/privilege-abuse issue rather than a remote-unauthenticated breach. Impact is constrained: VC:N (no confidentiality loss) with only VI:L/VA:L reflecting the ability to mass-delete imported candidate, company, and contact records (a bounded integrity/availability hit, not full system compromise), which is why the base score sits at 5.3 (medium). No EPSS score, KEV listing, or POC was provided in the intelligence set, so there is no signal of active or imminent exploitation; the fix is a single missing access-level check (CWE-862), which is trivial to understand from the public patch and could aid an attacker who already has an account. Net: real-world risk is driven by the trust model of a given OpenCATS deployment (how many low-trust READ users exist), not by mass internet exploitation - prioritize patching where untrusted or numerous low-privilege accounts exist, but it does not warrant emergency treatment absent exploitation evidence.

A disgruntled or compromised low-privilege OpenCATS user holding only READ-level access directly requests the import module's revert action, supplying an importID, because ImportUI::handleRequest() never checks the caller's access level. The rollback executes and mass-deletes the candidate, company, and contact records tied to that import, causing data loss across the recruiting database. No public exploit code was identified at time of analysis, but the fix is a one-line authorization check visible in the vendor patch.