CVE-2017-7309

This vulnerability lets someone who already has high-level access to MantisBT enter a “payload” that can show up as a harmful script in a configuration report page. If another user views that page, their browser may run the injected script, similar to how a doctored note can trick someone into clicking something dangerous. How bad it is depends on your browser protections (especially Content Security Policy).

This matters if your business runs MantisBT and has users with high privileges who can reach the configuration report page. It’s not a typical “open to the internet” problem—an attacker needs high-privilege access to use the configuration option in question. The risk is most relevant when that page is reachable in your setup and your Content Security Policy does not block script execution.

This should be treated as an update priority because the flaw is actively reachable inside the application and high-privileged users can trigger it. While no public exploit is on record and it’s not in the KEV list, predictions and growing attention suggest increasing risk over time—so don’t wait for evidence of real-world targeting.

1. Confirm exposure

   • Log into MantisBT as an admin and determine the exact installed MantisBT version.
   • Compare it to the fixed version: the vulnerability is fixed in MantisBT 1.3.9 (and also in later fixed branches, including 2.1.3+ and 2.2.3+).

2. Confirm reachability and exposure path

   • Identify which roles/users have access to the MantisBT Configuration Report page (adm_config_report.php).
   • Verify whether your deployment allows script execution in the browser (check your Content Security Policy settings). The findings note risk can be mitigated when CSP restricts script execution.

3. Apply the fix

   • Upgrade to MantisBT 1.3.9 or newer.
   • If you are on a 2.x branch, upgrade to a fixed version in that branch (2.1.3+ and 2.2.3+ are listed as fixed).

4. Temporary mitigation (if upgrade is delayed)

   • Reduce access: only allow a minimal set of trusted administrators/high-privilege users to reach the configuration report page.
   • Strengthen browser protection: verify your Content Security Policy is configured to restrict script execution, since the findings call out CSP as a mitigating factor.

5. What to monitor

   • After changes, watch for suspicious configuration changes around the time of any admin activity, and review web server/application logs for attempts to access the configuration report page by unexpected accounts.

(KEV) Not listed in the CISA KEV set, so there is no CISA “known exploited” due date tied to this issue from the provided findings.

This is a Cross-Site Scripting (XSS) vulnerability (CWE-79) in MantisBT’s configuration report page (adm_config_report.php). The mechanism described in the findings is that a high-privileged authenticated user can manipulate a configuration parameter (config_option) to inject malicious scripts, which may execute in other users’ browsers depending on security policies such as Content Security Policy (CSP).

Exploitation status: no public exploit code is on record, and it is not listed in the CISA KEV set (from the provided findings). However, the findings indicate reachable in default configuration (with mitigation possible if CSP restricts script execution) and predict rising likelihood (EPSS prediction provided in the findings, without KEV confirmation).

Attack requirements: the attacker must have high-level privileges to access the configuration report page; user interaction is required (another user viewing the page).