How to report a security issue

If you discover or learn about a potential error, weakness, or threat that can compromise the security of Mautic and is covered by the Security Advisory Policy, we ask you to keep it confidential and submit your concern to the Mautic security team.

To make your report please submit it as a private disclosure at You can also create a private fork to provide a fix, if you're able to do so. See the documentation from GitHub on privately reporting a security issue.

Screenshot of the GitHub security screen showing the report a vulnerability button which is highlighted with a red box surrounding it.

Do not post it in Github as a regular issue or a pull request, on the forums, or or discuss it in Slack.

The security team will investigate your report and then work with you and the Product Team to create a fix. If the fix is ready, we will create a release and announce the fix to a wide audience.

Some bugs take time to correct and the process may involve a review of the codebase for similar problems. Coordinating across time zones and work schedules can be time-consuming. We aim to fix issues within 1 month, but we also need to balance that with the available time of our volunteer team and the need to release high quality fixes.

Do not disclose the vulnerability to anyone else before the advisory is issued.

If the vulnerability is not covered by the Security advisory policy, you can still report it via these channels, but it's also acceptable to post it directly to Github.

How to make a good security report

Provide a detailed report. Each field in the form contains helpful information, please ensure you complete them all.

Screenshot of the vulnerability reporting screen from GitHub.

Use the following:

  • Ecosystem: Composer
  • Package name: Mautic (or plugin/package name as appropriate)
  • Affected versions: Please provide versions where this issue is present. You should test the current stable and development versions. See for details on how to spin up an instance on Gitpod for testing.
  • Patched version: Leave this field blank
  • Severity: Please use the calculator to create the CVSS scoring value which will be confirmed by the Security Team. More information on what each value means can be found in the CVSS user guide.
  • Weakness: Please choose the most appropriate CWE type which will be confirmed by the Security Team. Read more about the types on the Mitre CWE database.

Include in your description as many of these items as possible:

  • Short summary of the issue - a one-liner which explains what the vulnerability is about
  • Full details of the issue including code snippets where possible to provide deeper information.
  • Steps to reproduce the problem starting from a fresh install. Ensure you cover both the current stable and development versions.
  • Impact of the vulnerability.
  • A proposed fix or way of addressing the vulnerability, if possible. Once you submit the report you can make a private fork and submit the vulnerability fix - please make a separate PR for each branch.
  • Workarounds - are there any ways people can work around the vulnerability? Is there anything that can be done at the server-level to mitigate against abuse?
  • Resources - if sharing a vulnerability reported elsewhere, or there are links to similar vulnerabilities or other relevant resources, please include these in your report

Optional: you can indicate the way you would like to be referred to in the advisory about the vulnerability. Our preference is to credit people using full names and where appropriate an organisation when we are announcing a security fix, but at minimum your GitHub account will be mentioned. If you do not specify we will do our best to find that information. You can also request a pseudonym or having your name withheld.

The Mautic Security Team does not disclose proof-of-concept information to demonstrate vulnerabilities and reporters are encouraged to do the same.

Where a reporter feels strongly that proof-of-concept instructions should be published, they are encouraged to hold that information for an additional period of at least 4 weeks after the release of the patched version of the software.

What if the vulnerability affects a plugin that is not covered by the Security Advisory policy?

If you are absolutely sure that the plugin is not covered by the policy, you can report the issue in the Github issue queue of the plugin or follow their reporting process for security issues.

It is considered good form to copy in the [email protected] email list if possible when reporting issues with third party plugins so that the Security Team is aware, but the Mautic Security Team does not handle security advisories for plugins hosted elsewhere.