Vulnerabilities

Mautic allows you to update the application via an upgrade script. The upgrade logic isn't shielded off correctly, which may lead to vulnerable situation. This vulnerability is mitigated by the fact that Mautic needs to be installed in a certain way to be vulnerable.

When logging in with the correct username and incorrect weak password, the user receives the notification, that their password is too weak. However when an incorrect username is provided alongside with a weak password, the application responds with ’Invalid credentials’ notification. This difference could be used to perform username enumeration.

Prior to this patch, a stored XSS vulnerability existed in the contact tracking and page hits report.

Prior to this patch being applied, Mautic's tracking was vulnerable to Cross-Site Scripting through the Page URL variable.

With access to edit a Mautic form, the attacker can add Cross-Site Scripting stored in the html filed. This could be used to steal sensitive information from the user's current session.

The logic in place to facilitate the update process via the user interface lacks access control to verify if permission exists to perform the tasks. Prior to this patch being applied it might be possible for an attacker to access the Mautic version number or to execute parts of the upgrade process without permission. As upgrading in the user interface is deprecated, this functionality is no longer required.

Prior to the patched version, an authenticated user of Mautic could read system files and access the internal addresses of the application due to a Server-Side Request Forgery (SSRF) vulnerability.

Prior to the patched version, logged in users of Mautic are able to access areas of the application that they should be prevented from accessing. Users could potentially access sensitive data such as names and surnames, company names and stage names.

Prior to the patched version, logged in users of Mautic are vulnerable to an SQL injection vulnerability in the Reports bundle. The user could retrieve and alter data like sensitive data, login, and depending on database permission the attacker can manipulate file systems.

Prior to the patched version, logged in users of Mautic are vulnerable to a self XSS vulnerability in the notifications within Mautic. Users could inject malicious code into the notification when saving Dashboards.

ImpactThe default .htaccess file has some restrictions in the access to PHP files to only allow specific PHP files to be executed in the root of the application. This logic isn't correct, as the regex in the second FilesMatch only checks the filename, not the full path.

Prior to the patched version, logged in users of Mautic are vulnerable to Relative Path Traversal/Arbitrary File Deletion. Regardless of the level of access the Mautic user had, they could delete files other than those in the media folders such as system files, libraries or other important files. This vulnerability exists in the implementation of the GrapesJS builder in Mautic.

Prior to the patched version, there is an XSS vulnerability in the description fields within the Mautic application which could be exploited by a logged in user of Mautic with the appropriate permissions. This could lead to the user having elevated access to the system.

Users with low privileges can perform certain AJAX actions. In this vulnerability instance, improper access to ajax?action=plugin:focus:checkIframeAvailability leads to a Server-Side Request Forgery by analyzing the error messages returned from the back-end. Allowing an attacker to perform a port scan in the back-end. At the time of publication of the CVE no patch is available.

Users with low privileges (all permissions deselected in the administrator permissions settings) can view certain pages that expose sensitive information such as company names, users' names and surnames, stage names, and monitoring campaigns and their descriptions. In addition, unprivileged users can see and edit the descriptions of tags. At the time of publication of the CVE no patch is available.

Mautic uses predictable page indices for unpublished landing pages, their content can be accessed by unauthenticated users under public preview URLs which could expose sensitive data. At the time of publication of the CVE no patch is available

A cross-site scripting (XSS) vulnerability in the web tracking component of Mautic before 4.3.0 allows remote attackers to inject executable javascript

A cross-site scripting (XSS) vulnerability in the installer component of Mautic before 4.3.0 allows admins to inject executable javascript

For Mautic versions prior to 3.3.4/4.0.0, there is an XSS vulnerability on Mautic's password reset page where a vulnerable parameter, "bundle," in the URL could allow an attacker to execute Javascript code. The attacker would be required to convince or trick the target into clicking a password reset URL with the vulnerable parameter utilized.

The function mt_rand is used to generate session tokens, this function is cryptographically flawed due to its nature being one pseudorandomness, an attacker can take advantage of the cryptographically insecure nature of this function to enumerate session tokens for accounts that are not under his/her control This issue affects: Mautic Mautic versions prior to 3.3.4; versions prior to 4.0.0.

Mautic versions before 3.3.4/4.0.0 are vulnerable to an inline JS XSS attack when viewing Mautic assets by utilizing inline JS in the title and adding a broken image URL as a remote asset. This can only be leveraged by an authenticated user with permission to create or edit assets.

Mautic versions before 3.3.4/4.0.0 are vulnerable to an inline JS XSS attack through the contact's first or last name and triggered when viewing a contact's details page then clicking on the action drop down and hovering over the Campaigns button. Contact first and last name can be populated from different sources such as UI, API, 3rd party syncing, forms, etc.

Insufficient sanitization / filtering allows for arbitrary JavaScript Injection in Mautic using the bounce management callback function. The values submitted in the "error" and "error_related_to" parameters of the POST request of the bounce management callback will be permanently stored and executed once the details page of an affected lead is opened by a Mautic user. An attacker with access to the bounce management callback function (identified with the Mailjet webhook, but it is assumed this will work uniformly across all kinds of webhooks) can inject arbitrary JavaScript Code into the "error" and "error_related_to" parameters of the POST request (POST /mailer/<product / webhook>/callback). It is noted that there is no authentication needed to access this function. The JavaScript Code is stored permanently in the web application and executed every time an authenticated user views the details page of a single contact / lead in Mautic. This means, arbitrary code can be executed to, e.g., steal or tamper with information.

In all versions prior to Mautic 3.3.2, secret parameters such as database credentials could be exposed publicly by an authorized admin user through leveraging Symfony parameter syntax in any of the free text fields in Mautic’s configuration that are used in publicly facing parts of the application.