Contao CMS EUVD-2026-95973

Exploitation requires that the target Contao site expose a page containing the registration module AND that the registration module has activation-by-email enabled (reg_activate = true). For the email-flooding and positive enumeration outcome, the probed email address must already have an unconfirmed registration with a valid, pending opt-in token; addresses with no pending registration only yield the negative side of the enumeration oracle. No authentication, no user interaction, and no special client privileges are needed (PR:N/UI:N), and it works against affected default-configured registration pages, but the dependence on reg_activate being enabled and on target-side pending-registration state is the key limiting factor that reduces realistic impact.

This is a genuine but modest-severity information-disclosure and email-abuse issue, not a high-priority emergency. The CVSS 3.1 base score of 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) correctly reflects a low-confidentiality impact: an unauthenticated remote attacker can determine whether a given email address has a pending (unconfirmed) registration (CWE-204, observable response discrepancy) and can trigger repeated activation emails to that address because resendActivationMail() invoked OptInToken::send() without rate limiting. No EPSS score was provided, and the CVE is NOT in CISA KEV, so there is no evidence of active exploitation - exploitation status is 'no public exploit identified at time of analysis.' The GitHub source evidence is the vendor fix commit (adding FORM_SUBMIT/captcha checks and a rate limiter), NOT weaponized exploit code, so POC availability should not be read as a working public exploit. The signals are internally consistent: a network-reachable, low-complexity, unauthenticated flaw with only low confidentiality impact and no integrity/availability impact. The main caveat not captured by AC:L is that successful abuse depends on target-side state (reg_activate enabled AND the target email already having an unconfirmed registration with an opt-in token), which meaningfully narrows real-world applicability - verify your deployment uses the registration module with activation enabled before prioritizing.

An attacker POSTs an email address to a public page hosting Contao's registration module; because the follow-up branch no longer required FORM_SUBMIT or a passed captcha, the differing response reveals whether that address has a pending registration, enabling account enumeration. If a pending registration exists, the attacker repeats the request to flood the victim's inbox with activation emails since OptInToken::send() was not rate limited. No public weaponized exploit is identified; only the vendor fix commit is available.