How the Mautic Security Team triages and resolves reported security issues

The basic workflow that the Mautic Security Team follows is:

  • Review the issue and evaluate the potential impact on all supported releases of Mautic.
  • If it is indeed a valid problem, the security team mobilises the team to eliminate it.
  • New versions are created, reviewed, and tested.
  • New releases are created on Github.
  • When an issue has been fixed, we use all available communication channels to inform users of steps that must be taken to protect themselves.

The Mautic Security Team aims to ensure all issues are handled in a timely manner and for clear communication between the team and issue reporters. As such, we have established the following guidelines for responding to issue reports:

  • Within 24 hours every report gets acknowledged.
  • Within 7 days every report gets a further response stating either:
    • the issue is closed (and why);
    • the issue is still under investigation; if needed, additional information will be requested.
  • Within 21 days every report must be resolved unless there are exceptional circumstances requiring additional time.

Unless the threat level dictates otherwise, security patches will be rolled into the next available release.

Vulnerability threat levels

The security advisory risk level system is based on the NIST Common Misuse Scoring System (NISTIR 7864). Each vulnerability is scored using this system and a number is assigned between 0 and 25.

The total points are used to give a text description to make the numbers easier to understand:

  • Scores between 0 and 4 are considered Not Critical
  • 5 to 9 is considered Less Critical
  • 10 to 14 is considered Moderately Critical
  • 15 to 19 is considered Critical
  • 20 to 25 is considered Highly Critical

The risk level is assigned by a Risk Calculator which takes 6 different metrics, each which can have 3 different values.

This is encoded in a terse format and included on every Security Advisory.

The below table provides longer descriptions and point scores for each category. 

Code

Metric

Description

AC

Access complexity

How difficult is it for the attacker to leverage the vulnerability?

  • AC:None = None (user visits page) +4 points
  • AC:Basic = Basic or routine (user must follow specific path) +2 points
  • AC:Complex = Complex or highly specific (multi-step, unintuitive process with high number of dependencies) +1 point

A

Authentication

What privilege level is required for an exploit to be successful?

  • A:None = None (all/anonymous users) +4 points
  • A:User = User-level access (basic/commonly assigned permissions) +2 points
  • A:Admin = Administrator (broad permissions required) +1 point

CI

Confidentiality impact

Does this vulnerability cause non-public data to be accessible?

  • CI:All = All non-public data is accessible +5 points
  • CI:Some = Certain non-public data is released +3 points
  • CI:None = No confidentiality impact +0 points

II

Integrity impact

Can this exploit allow system data (or data handled by the system) to be compromised?

  • II:All = All data can be modified or deleted +5 points
  • II:Some = Some data can be modified +3 points
  • II:None = Data integrity remains intact +0 points

E

Exploit (Zero-day impact)

Does a known exploit exist?

  • E:Exploit = Exploit exists (documented or deployed exploit code already in the wild) +4 points
  • E:Proof = Proof of concept exists (documented methods for developing exploit exist in the wild) +2 points
  • E:Theoretical = Theoretical or white-hat (no public exploit code or documentation on development exists) +1 point

TD

Target distribution

What percentage of users are affected?

  • TD:All = All module configurations are exploitable +3 points
  • TD:Default = Default or common module configurations are exploitable, but a config change can disable the exploit +2 points
  • TD:Uncommon = Only uncommon module configurations are exploitable +1 points

Security announcement and release process

Providing security requires more than simply posting a patch release. Hundreds of thousands of people rely on the Mautic Security Team to notify them of known vulnerabilities.

The Security Team coordinates security announcements in release cycles and evaluates whether security issues are ready for release several days in advance.

The team may deem it necessary to make an out-of-sequence release, in which case at least two weeks’ notice will be provided to ensure that Mautic users are made aware of a security release being made on an unscheduled basis.

If you are concerned with the response time or the handling of a security issue, please send an email to [email protected]. You may publicly discuss the policy, but not the details of any non-disclosed issue.

There are past security announcements: Security announcements

Disclosure policy

The security team follows a Coordinated Disclosure policy: we keep issues private until there is a fix.

Public announcements are made when the threat has been addressed and a secure version is available.

When reporting a security issue, observe the same policy. Do not share your knowledge of security issues with others.

Which versions are supported?

Please check the Releases page for the currently supported versions.

Development branches and alpha, beta and release candidate releases are not intended for production use.

Upgrade if you are using an unsupported version of Mautic.

Our security advisory policy has a detailed description of this process and which releases get advisories.