What is a Security Advisory?

A security advisory is a public announcement managed by the Mautic Security Team which informs Mautic users about a reported security problem in Mautic core or an officially supported plugin and the steps Mautic users should take to address it. (Usually this involves updating to a new release of the code that fixes the security problem.)

The problem is kept secret until the advisory is ready to be released, at which point it is publicized widely so that Mautic users can address it quickly.

Occasionally, the security team may issue a public service announcement before a security release, notifying users that a specific release is upcoming. This can be done for highly critical or critical issues which we feel might be easily turned into automated attacks.

Which Plugins are Covered?

Plugins that are part of the official Mautic organisation on Github are maintained by the Mautic Community and supported by the Product Team.

Which Releases Get Security Advisories?

Mautic core Mautic 3 will receive security advisories until 15 December 2021.

Starting with the release of Mautic 3.0, one minor versions at a time receives security advisories, the most recent minor release.

For example, Mautic 3.1 will continue receiving security advisories until the release of Mautic 3.2, and 3.2 will receive security advisories until the release of 3.3.

Supported Versions

* = Security Support for 2.16 will only be provided for Mautic itself, not for core dependencies that are EOL like Symfony 2.8.

Security advisories are only made for issues affecting stable releases in the supported major version branches. That means there will be no security advisories for development releases (-dev), alphas, betas or release candidates.

What About Vulnerabilities in External Libraries or Plugins?

Since security advisories are only issued for Mautic core and officially supported plugins, no advisories will be issued for external libraries or plugins, even if a Mautic plugin requires you to install an external library as a requirement for using it.

This policy applies regardless of the method used to install the external library (for example, either manually or using a tool such as Composer).

Mautic core ships with copies of several external libraries that are included as part of the downloaded package (for example, the jQuery JavaScript library). Security advisories will be issued in the event of a vulnerability in one of those particular external libraries.

What About Vulnerabilities Which Require Advanced Permissions?

Another case where no security advisory is required is when an exploit requires full administrator access to Mautic. Any user with this level of permissions can already take over the Mautic instance or bypass various access restrictions on the site, so there is no meaningful added risk if a vulnerability is only accessible to a user with these permissions.

What about security issues that can't be exploited?

There are often instances where it is unlikely that an issue can be exploited on actual Mautic instances. In these cases the team considers several elements to determine whether the issue should be handled publicly or as a private security issue:

• If there is a way to exploit the issue by installing a plugin then it should probably be handled in private.
• If the steps to exploit the issue are extremely complex it can more likely be handled in public.
• If the solution is likely to be controversial or difficult to get right then it is more likely it should be handled in public.
• If there is no known way to exploit the issue and it's difficult to imagine a way to exploit it without some other attack already in place (e.g. SQL injection) then the issue can probably be handled in public.
• If the issue is related to insecure cryptographic storage of keys (e.g. they are stored in plain text in the database) that is disclosed or reasonably expected of the plugin then the issue can be handled in public.
• If a plugin stores sensitive user information in a non-encrypted format that should be handled as a private issue.

For example, an issue that requires a username that contains XSS cannot be exploited with core alone because core has validation on usernames. However, it is likely that a plugin importing users or making usernames from an external source (like distributed authentication) will allow non-standard usernames that might contain malicious characters. So, issues should be handled privately and with an Advisory to fix XSS in user names. On the other hand, an XSS issue related to other names (e.g. languages) that are unlikely to be entered/imported from an untrusted source can be handled in public.

Always report the issue to the team and let them make the decision on whether to handle it in public or private.