OpenCATS CVE-2026-112784

Requires a valid authenticated OpenCATS session at the lowest ('read') access level - the flaw is that ajax/testEmailSettings.php performed no authorization check before invoking the mail-test routine (the patch adds a required ACCESS_LEVEL_SA check). The configured SMTP relay/email settings must already be set up on the server for mail to actually be relayed. Limiting factors: authentication is mandatory (PR:L), the attacker cannot control the message body (only a fixed test message is sent), and impact is confined to sending spoofed-From mail - no data disclosure, record modification, or availability impact. Fixed in OpenCATS 0.10.0.

This is a genuine but moderate-severity issue, not a top priority. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the description agree: exploitation is network-reachable and low-complexity but requires an existing authenticated account (PR:L, a 'read-level' user), so this is a privilege/authorization flaw (CWE-862 missing authorization), not a pre-auth break. Impact is limited - VI:L with VC:N/VA:N reflects that the attacker can only send a fixed test message with a spoofed From address through the already-configured SMTP relay, not read data, alter records, or disrupt availability. No EPSS score, KEV listing, or SSVC decision data was supplied, and no POC is referenced, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the realistic risk is abuse of the server as a spoofed-mail/phishing or spam relay by insiders or attackers who already hold a low-privilege account. The signals are internally consistent - there is no CVSS-vs-description conflict here - but note that automatable mass exploitation is constrained by the authentication requirement.

An attacker holding any low-privilege ('read-level') OpenCATS account sends a crafted AJAX request to ajax/testEmailSettings.php with attacker-chosen testEmailAddress and fromAddress parameters, causing the server to relay a test email to an arbitrary recipient with a forged sender. This lets the attacker leverage the organization's trusted, configured SMTP relay for spoofed phishing or spam. No public POC is referenced; exploitation requires a valid authenticated session (PR:L) but is otherwise low-complexity.