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