CVE-2026-115196 in Mautic
Summary
by MITRE • 10/26/2026
An Open Redirect vulnerability exists in the public form submission endpoint (/form/submit) of Mautic. After a form is submitted, the application redirects the visitor to a return address supplied with the submission without verifying that it points to the Mautic instance or another trusted host. An unauthenticated attacker can exploit this to send visitors from a legitimate Mautic domain to an arbitrary external website, for example to phishing pages that imitate the original landing page or to sites that deliver malware. Any Mautic instance with a published form is affected. Exploitation requires the victim to submit a form prepared by the attacker.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in Mautic represents an Open Redirect flaw within its public-facing API, specifically targeting the /form/submit endpoint which handles data submission for user-created forms. This security defect stems from insufficient validation of the return address parameter provided during a form submission event. When a visitor completes and submits a form hosted on a legitimate Mautic instance, the application is designed to redirect the user to a specified destination URL rather than remaining on the current page or showing a generic success message. However, the underlying logic fails to verify whether this target URL belongs to the same domain as the Mautic installation or another trusted host within an allowlist. Consequently, any arbitrary external URI can be passed through this parameter without triggering security checks, allowing the application to perform an HTTP redirect to locations entirely controlled by third parties.
From a technical perspective, this flaw aligns with CWE-601, which defines Open Redirect vulnerabilities as cases where an attacker influences the redirection target of a web application in a way that bypasses trust boundaries. The absence of strict domain validation or canonicalization checks means that malicious actors can craft URLs containing their own domains within the redirect parameter. This lack of input sanitization is particularly dangerous because it exploits the inherent trust users place in established and reputable websites. By leveraging this mechanism, an attacker does not need to compromise the server itself but rather manipulates the client-side navigation flow based on user interaction with a compromised form submission process.
The operational impact of this vulnerability extends beyond simple misdirection, as it serves as a potent vector for social engineering attacks such as phishing and credential harvesting. An unauthenticated attacker can distribute links pointing to legitimate Mautic instances but configured to redirect victims immediately upon form submission to malicious sites that mimic the appearance of trusted services like banking portals or email providers. Because the initial part of the URL path displays the authentic domain name, users are significantly more likely to trust the subsequent redirection and enter sensitive information on the fraudulent site. Additionally, this vulnerability can be weaponized for malware distribution by redirecting victims to domains hosting drive-by download exploits or malicious scripts that compromise end-user devices without their knowledge or consent.
This attack scenario is consistent with tactics observed in the MITRE ATT&CK framework, specifically under T1566.002 which covers Phishing: Spearphishing Link. The attacker leverages a trusted domain to increase the click-through rate of malicious links, thereby bypassing user skepticism and security awareness training that might otherwise prevent engagement with obviously suspicious URLs. Furthermore, it relates to T1189 Drive-by Compromise if the redirect leads directly to exploit kits or malware hosting infrastructure. Any Mautic instance that exposes public forms is susceptible to this exploitation vector, making widespread instances particularly vulnerable to coordinated campaigns aimed at harvesting credentials or distributing malicious payloads through deceptive redirection chains.
Mitigation strategies must focus on implementing strict validation mechanisms for all user-supplied input used in redirect operations. Developers should enforce a whitelist approach where only pre-approved domains are permitted as valid return addresses rather than attempting to blacklist known bad actors, which is often ineffective due to the infinite variety of malicious domains. Alternatively, if open redirections are necessary for functionality, the application should encode or hash the destination URL and verify its integrity server-side before executing the redirect. For immediate remediation without code changes, administrators can configure web servers like Nginx or Apache to inspect request parameters and block those containing suspicious patterns such as double slashes followed by arbitrary domains in query strings targeting the /form/submit endpoint. Regular security audits of form handling logic are essential to ensure that trust boundaries are correctly enforced across all public-facing endpoints within the Mautic ecosystem.