OpenCATS CVE-2026-112785

Requires a valid authenticated OpenCATS account at READ access level (PR:L) that can reach the saved-list AJAX endpoints /modules/lists/ajax/newList.php, editListName.php, deleteList.php, and addToLists.php; no user interaction or special non-default configuration is needed. The limiting factor is the authentication requirement - the attacker must already possess or obtain low-privilege credentials, and exploitation is confined to OpenCATS instances running a version before 0.10.0. There is no confidentiality exposure (lists cannot be read out, only altered/deleted), which bounds the realistic impact to integrity/tampering of saved lists.

This is a genuine but modest-severity broken-access-control issue, not a high-urgency emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms network-reachable, low-complexity exploitation but requires authentication (PR:L) - specifically an existing READ-level account - and the impact is limited to integrity (VI:L) with no confidentiality (VC:N) or availability (VA:N) effect, yielding the 5.3 Medium score. No EPSS score, CISA KEV listing, or public POC was provided in the intelligence set, so there is no signal of active or probable exploitation; under the SSVC lens this reads as low automatable value and partial technical impact against a niche product. The practical risk is therefore an insider or compromised-low-privilege-account scenario rather than mass internet exploitation. One data caveat: the tag 'Authentication Bypass' conflicts with the actual nature of the flaw (CWE-862 Missing Authorization, which presupposes an authenticated user) - treat the vuln as privilege/authorization abuse by an already-authenticated low-privilege user, not a pre-auth bypass.

A user holding only a READ-level OpenCATS account (or an attacker who has phished/compromised such low-privilege credentials) sends crafted AJAX POST requests to newList.php, editListName.php, deleteList.php, or addToLists.php supplying arbitrary savedListID values. Because the endpoints never check access level, the attacker can rename, repopulate, or delete any saved list belonging to any user site-wide. No public exploit code was identified at time of analysis, though the vulnerable endpoints and fixing commit are openly documented on GitHub.