Cross-site Scripting (XSS) - Stored in mautic/mautic

Valid

Reported on

Jan 12th 2022


Description

When installing Mautic (both via UI or CLI) the first and last name of the admin account are not sanitised before being stored in the database.
This results in a possible stored XSS possibility, as those fields are displayed and re-used without any sanitisation.

During install the raw user input is stored without sanitisation, see codebase
Mautic uses that data to determine the name of a user in the User::getName() method, see codebase

That method is used to:

  • display the name in the the user's menu, see codebase
  • display the name on the profile page of that user, see codebase
  • persistently store the name as createdByUser value on every entity that uses the FormEntity as base class ( e.g. segment, contact, form, campaign, ... ), see codebase

Because that name is stored on every entity, following issues occurs as side effect:

  • The createdByUser value is displayed without any sanitisation in a generic helper template, see codebase
  • That template is used on the detail page of entities, e.g. on a campaign

Proof of Concept

  1. Install a vanilla Mautic 3 or 4 via UI or CLI, and use <script>alert('XSS')</script>firstname as admin first name in the install process.
  2. login to Mautic, and you will get the XSS alert
  3. create an entity in Mautic (a Segment, Contact, Form, ...)
  4. change your first name to remove the XSS part
  5. go to your profile, and the XSS alert is not present anymore
  6. go to the detail page of the entity you just created, and the XSS is still there

Impact

While this may look like a not so impactful issue (why would an admin add stored XSS to his own Mautic instance?), following scenario is possible:

  • someone does the initial installation of Mautic for you, without any direct access to database or server.
  • he and adds an XSS payload to his first or last name during install
  • he creates content that will be generally used by other users in the Mautic installation, e.g general segments, forms, ...
  • he changes the first and last name again so everything looks normal
  • you reset the password and email address of that account to prevent access from the other party.
  • every time you visit an entity the initial admin created, the XSS fires as the initial admin's name with XSS payload is still displayed

Occurrences

When installing Mautic (both via UI or CLI) the first- and lastname of the admin account are not sanitised before being stored in the database.

We are processing your report and will contact the mautic team within 24 hours. 5 months ago
mollux submitted a
5 months ago
mollux modified the report
5 months ago
Ruth Cheesley
5 months ago

Maintainer


Thanks for reporting the issue! I'll pass this along to the security team for them to review.

We have contacted a member of the mautic team and are waiting to hear back 5 months ago
We have sent a follow up to the mautic team. We will try again in 7 days. 5 months ago
We have sent a second follow up to the mautic team. We will try again in 10 days. 5 months ago
Jamie Slome
5 months ago

Admin


@mollux - I understand that you are potentially looking to submit another XSS report via our platform to the mautic maintainers.

We do encourage vulnerabilities of the same weakness to be submitted together, but just so we can form a better opinion, can you help us understand your situation and new report?

mollux
5 months ago

Maintainer


Hi, the XSS in this report is in the installer part, and requires a specific ownership over the setup phase of mautic.

The new vulnerabilities are also stored XSS, but are present for any logged in user with mail rights (which is almost every logged in user), and is also publicly accessible by anonymous users. So even though they are the same type of vuln, they have a very different vector and impact.

We have sent a third and final follow up to the mautic team. This report is now considered stale. 5 months ago
Jamie Slome
5 months ago

Admin


@mollux - apologies for the delay in my response.

For now, I'd recommend waiting for this report to be in/validated, and then disclosing the new report, or including it in this report.

I understand that they have a different vector and impact, and so submitting in a new report, once this has been addressed is probably the best course of action for now.

However, I have shared this with the team, and we will discuss better mechanisms to make this easier in the future.

Let me know if you have any further questions or need anymore support - my door is open!

Ruth Cheesley validated this vulnerability 5 months ago
mollux has been awarded the disclosure bounty
The fix bounty is now up for grabs
Ruth Cheesley
5 months ago

Maintainer


Thanks for the issue report, confirmed in 4.x and as you suggest it should probably also happen in the 3.x branch as well so we'll need to back-port the fix.

This is being tracked by the security team in MST-28 for reference.

Are you able to make a PR to address this? If so we will create a private fork against the security advisory to work on - please do not work on this in a personal fork.

mollux submitted a
5 months ago
mollux
5 months ago

Maintainer


Hi, I already added the patch to this issue, I just retried it, but it disappears here. see https://github.com/mollux/mautic/tree/installer

Ruth Cheesley
5 months ago

Maintainer


Adding the link to the advisory just for consistency: https://github.com/mautic/mautic/security/advisories/GHSA-jrwm-pr9x-cgq3 - this is where we'll work on the fix.

We have sent a fix follow up to the mautic team. We will try again in 7 days. 5 months ago
We have sent a second fix follow up to the mautic team. We will try again in 10 days. 4 months ago
We have sent a third and final fix follow up to the mautic team. This report is now considered stale. 4 months ago
Jamie Slome confirmed that a fix has been merged on d1518c 19 days ago
mollux has been awarded the fix bounty
to join this conversation