Oct 10, 2026·4 min read·4 visits
Unauthenticated attackers can send repeated HTTP POST requests to Contao registration pages to trigger activation emails without captcha verification or rate limiting, causing mail flooding and unconfirmed account enumeration.
Contao CMS versions 4.1.0 through 5.3.49 and 5.4.0-RC1 through 5.7.11 fail to validate form submission tokens and enforce rate limiting when processing activation email resend requests via HTTP POST, enabling resource exhaustion and account state enumeration.
Contao Open Source Content Management System exposes an attack surface within its registration module handling logic (ModuleRegistration::compile()). When the activation setting reg_activate is enabled, the system handles follow-up account registration requests for users who have not yet confirmed their accounts via email.
The vulnerability allows unauthenticated remote attackers to submit HTTP POST requests targeting registration endpoints without verifying form submission tokens or completing captcha checks. This flaw compromises the application's resource management and anti-automation checks during registration workflows.
Classified under CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-204 (Observable Response Discrepancy), this issue exposes endpoints to automated mail dispatch generation and membership state disclosure.
The root cause lies within ModuleRegistration::compile(), where conditional checks evaluated whether to execute follow-up registration actions. Specifically, the execution branch evaluated Input::post('email', true) and performed a lookup via MemberModel::findUnactivatedByEmail(), without checking whether the form was legitimately submitted or passed anti-automation validations.
In standard Contao form processing, form submissions set Input::post('FORM_SUBMIT') to match the internal form ID $strFormId. Furthermore, validation filters set the flag $doNotSubmit to true whenever captcha challenges fail or mandatory fields contain invalid formatting. In affected versions, ModuleRegistration::compile() evaluated the follow-up branch prior to or independently of these parameters.
When a matching unactivated user record was found, the code directly called resendActivationMail($objMember). Inside resendActivationMail(), the application instantiated OptInToken::send() without evaluating rate limit counters or tracking submission frequency, allowing unlimited invocation per IP or user ID.
The vulnerability fix was committed to contao/contao under commit 2ea6117f9049db7221679251cfc41e67d941a74b. The fix modifies core-bundle/contao/modules/ModuleRegistration.php to enforce submission validation and introduces rate limiting via the Symfony service container.
// Vulnerable Condition:
if ($this->reg_activate && Input::post('email', true) && ($objMember = MemberModel::findUnactivatedByEmail(Input::post('email', true))) !== null)
// Patched Condition:
if (!$doNotSubmit && Input::post('FORM_SUBMIT') == $strFormId && $this->reg_activate && Input::post('email', true) && ($objMember = MemberModel::findUnactivatedByEmail(Input::post('email', true))) !== null)The updated condition ensures that the follow-up logic executes only if $doNotSubmit is false and FORM_SUBMIT matches $strFormId. Additionally, the patch modifies resendActivationMail() to integrate the rate limiter:
$factory = System::getContainer()->get('contao.rate_limit.member_password_factory');
$limiter = $factory->create($objMember->id);
if (!$limiter->consume()->isAccepted())
{
$this->Template->type = 'error';
$this->Template->message = $GLOBALS['TL_LANG']['MSC']['tooManyResendActivationAttempts'];
return;
}An unauthenticated attacker executes this vulnerability by transmitting automated HTTP POST requests directly to any page hosting a Contao registration module. The body of the request includes the email field containing a target email address.
Because the vulnerable function did not validate FORM_SUBMIT or captcha fields, anti-bot controls placed on the registration form are entirely bypassed. Each request triggers an outbound SMTP email containing a new opt-in token to the specified recipient address.
Furthermore, the application returns observable response discrepancies depending on whether the specified target email corresponds to a pending, unconfirmed account registration. An attacker can analyze response templates to harvest information on active pending registrations across the system.
The primary impact of CVE-2026-107843 consists of resource exhaustion and observable response discrepancies. The flaw allows external actors to flood victim email inboxes with repetitive activation notifications and consume host SMTP server resources.
The CVSS v3.1 score is evaluated at 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). Confidentiality impact is Low due to the ability to disclose unconfirmed account registration states. Integrity and Availability impacts are rated None at the primary application layer, though downstream email server resources are subject to operational strain.
According to EPSS data, the exploit probability score is 0.00255 (15.79th percentile). The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no public active exploitation scripts have been reported.
To remediate CVE-2026-107843, administrators must update Contao installations to the patched versions: Contao 5.3.50 for the 5.3 release train, or Contao 5.7.12 for the 5.7 release train.
If immediate software updates cannot be deployed, web application firewalls (WAF) or reverse proxies should be configured to rate limit incoming HTTP POST requests directed at registration module URLs containing the email field.
Monitoring logic should be implemented to identify anomalous clusters of HTTP POST requests targeting registration endpoints, specifically monitoring log patterns for repeated resend responses.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
Contao Open Source CMS Contao | >= 4.1.0, < 5.3.50 | 5.3.50 |
Contao Open Source CMS Contao | >= 5.4.0-RC1, < 5.7.12 | 5.7.12 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-770, CWE-204 |
| Attack Vector | Network (Unauthenticated HTTP POST) |
| CVSS v3.1 | 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) |
| EPSS Score | 0.00255 (15.79th percentile) |
| Impact | Email Flooding / Account State Enumeration |
| Exploit Status | Unproven / No Public Exploit |
| CISA KEV Status | Not Listed |
The application allocates limited resources such as outbound email dispatch without imposing rate limits or checking form validation tokens.
Contao Open Source CMS versions 4.0.0 through 5.3.49 and 5.4.0-RC1 through 5.7.11 contain a Cross-Site Request Forgery (CSRF) vulnerability in backend parameter handling. The `RequestTokenListener` component validates anti-CSRF tokens solely for HTTP POST requests, while GET-based declarative guards run only when an `act` parameter is present in the query string. Consequently, custom backend actions dispatched via alternative parameters such as `key=` can execute without CSRF token verification when triggered by an authenticated user.
An information disclosure vulnerability in Contao CMS allows unauthenticated site visitors to view protected page titles, URLs, and text excerpts through search queries when protected page indexing is disabled after previously being enabled.
In Vikunja prior to version 2.6.0, relation creation via the CalDAV endpoint fails to invoke the TaskRelation.CanCreate authorization check. This missing access control allows an authenticated user to establish unauthorized relationships and perform write operations against any task, provided its unique identifier (UID) is known.
A cross-project information disclosure vulnerability in Vikunja allows authenticated users with read access to one project to view private task details from unauthorized projects via subtask expansion parameters.
An information disclosure vulnerability in Vikunja allows authenticated users with read access to a task to expose private email addresses of assigned users through the API task assignees endpoint due to an unmasked database query.
An authorization bypass vulnerability in Vikunja versions prior to v2.6.0 permits authenticated users to delete relationships between tasks across project boundaries without requiring read or write authorization for the target related task.