The Mautic application is affected by stored XSS vulnerabilities. Upon exploitation, these issues allow an authenticated attacker to store malicious JavaScript payloads that would execute against other Mautic users. Specifically, an attacker with the permissions to manage companies or Social Monitoring, an application feature, could attack other users, including administrators. For example, by loading an externally crafted JavaScript file, an attacker could eventually perform actions as the target user. These actions include changing the user passwords, altering user or email addresses, or adding a new administrator to the system.
An authenticated attacker with the permissions to manage companies or Social Monitoring could target and perform actions on the behalf of other users, including administrators.
Medium
|
Product Vendor |
Product Name |
Affected Version |
| Mautic | Mautic | <= 3.2.2 |
Mautic is an open source marketing automation tool. The project’s official website is https://www.mautic.org/. The latest version of the application is 3.2.4 released on January 14, 2021.
One vulnerability was identified within the Mautic application:
Update to version 3.2.4
The Mautic application is affected by stored XSS vulnerabilities. These issues allow an authenticated attacker to store malicious JavaScript payloads that would execute against other Mautic users. Specifically, an attacker with the permissions to manage companies or Social Monitoring could attack other users, including administrators. For instance, by loading an externally crafted JavaScript file, an attacker could eventually perform actions on behalf of the target user, including changing the user’s password or email address or adding a new administrator to the system.
|
CVE ID |
Security Risk |
Impact |
Access Vector |
| Medium | Escalation of privileges | Remote |
A stored XSS vulnerability was found in the Company Name
Figure 1 - Company Name
As shown in the following POST request, the XSS payload was used in the company[companyname]
POST /mautic/s/companies/edit/1?mauticUserLastActive=4764&mauticLastNotificationId= HTTP/1.1
Host: localhost
…omitted for brevity…
company%5Bscore%5D=0&company%5Bowner%5D=&>company%5Bcompanyname%5D=%3Cimg+src%3Dx+onerror%3Dconfirm('XSS')%3E&company%5Bcompanyemail%5D=&company%5Bcompanyaddress1%5D=&company%5Bcompanyaddress2%5D=&company%5Bcompanycity%5D=&company%5Bcompanystate%5D=&company%5Bcompanyzipcode%5D=&company%5Bcompanycountry%5D=&company%5Bcompanyphone%5D=&company%5Bcompanywebsite%5D=&company%5Bcompanynumber_of_employees%5D=&company%5Bcompanyfax%5D=&company%5Bcompanyannual_revenue%5D=&company%5Bcompanyindustry%5D=&company%5Bcompanydescription%5D=&company%5B_token%5D=kAayMpWGSe_npJC64UDzpgtMHDeFLGx4CAptt1mDzH8&company%5Bbuttons%5D%5Bsave%5D=
Figure 2 - Affected parameter in POST request
As soon as the change was saved, the XSS triggered:
Figure 3 - Triggered XSS after creating or editing company
Additionally, this XSS triggered on several locations. For example, the default Dashboard had a Recent Activity widget that retrieved all recent activities. As a result, when the company with a malicious JavaScript code was added, it appeared on the Dashboard:
Figure 4 - Triggered XSS on Dashboard page
The company with the XSS payload could also be selected when adding a new contact:
Figure 5 - Selecting malicious company while creating or editing a contact
When the contact was added or viewed, the XSS triggered:
Figure 6 - Triggered XSS while viewing a contact
The default Mautic installation featured a single user role that had full administrative access; however, it was possible to create less-privileged user roles. If a less-privileged user role had access only to create companies, that user could inject an XSS payload to perform actions on behalf of those users.
A stored XSS issue was also discovered within the Social Monitoring section. Specifically, an attacker could enter a malicious JavaScript payload in the NameTitle
Figure 7 - Social Monitor Name allowing XSS payloads
The following HTTP POST request was used to store the XSS payload:
POST /mautic/s/monitoring/edit/1?mauticUserLastActive=180&mauticLastNotificationId= HTTP/1.1
Host: localhost
…omitted for brevity…
monitoring%5Btitle%5D=AAA%3Cimg+src%3Dx+onerror%3Dconfirm(1)%3E&monitoring%5BnetworkType%5D=twitter_handle&monitoring%5Bproperties%5D%5Bhandle%5D=bishopfox&monitoring%5Bproperties%5D%5Bchecknames%5D=0&monitoring%5Bdescription%5D=Test&monitoring%5BisPublished%5D=1&monitoring%5BpublishUp%5D=&monitoring%5BpublishDown%5D=&monitoring%5Bcategory%5D=&monitoring%5B_token%5D=4eSQ1YrFcdj3xdVfIcXiDQBkKnpSZa8dLZ1az8_YVWU&monitoring%5Bbuttons%5D%5Bsave%5D=
Figure 8 - POST request with XSS payload in the monitoring[title]
The XSS payload was evaluated as soon as the modified Social Monitor was viewed:
Figure 9 - Triggered XSS after opening Social Monitor
As with the previous XSS instance affecting company names, even if a user role had access only to Social Monitoring, that user could eventually attack other Mautic users, including administrators, by injecting malicious payloads. For instance, an attacker could load an externally drafted JavaScript file that would allow them to eventually perform actions on the target user’s behalf, including changing the user’s password or email address or changing the attacker’s user role from a low-privileged user to an administrator account.