CVE-2026-30849: Authentication Bypass via Type Juggling in MantisBT SOAP API

Mantis Bug Tracker (MantisBT) is a widely deployed open-source issue tracking system. The software exposes a SOAP API to facilitate programmatic interaction, integration with third-party tools, and automated workflow management. This API handles authentication via credentials supplied within the SOAP envelope payload. Versions of MantisBT prior to 2.28.1 contain a critical authentication bypass vulnerability within this API implementation.

The vulnerability, classified as CWE-305 (Authentication Bypass by Primary Weakness), exists exclusively in deployments utilizing MySQL or MariaDB as the backend database. Installations running on PostgreSQL or Microsoft SQL Server are immune to this specific attack vector. This environment-specific constraint arises due to fundamental differences in how relational database management systems handle implicit data type conversion during comparison operations.

The flaw allows an unauthenticated remote attacker to gain authorized access to any known user account, including administrative profiles. The attacker does not need to guess or brute-force the password. By exploiting the type handling mechanics between PHP and MySQL, the attacker forces the authentication routine to evaluate the password validation check as true regardless of the stored cryptographic hash.

The root cause of CVE-2026-30849 is a type-juggling vulnerability caused by the combination of PHP's SOAP deserialization behavior and MySQL's implicit type conversion rules. When the PHP SoapServer class processes an incoming XML request, it inspects the explicitly declared data types within the SOAP envelope. If an XML element specifies xsi:type="xsd:int", the PHP SOAP extension automatically deserializes the value into a native PHP integer type.

In the vulnerable application state, the mci_check_login function in api/soap/mc_api.php accepts the $p_password parameter without strict type validation or type hinting. Consequently, if an attacker submits an integer payload, the variable retains its integer type throughout the application logic. This integer variable is eventually incorporated into the database query used to fetch and validate the user's password hash.

The vulnerability triggers within the MySQL database engine during the execution of the credential verification query. When MySQL is instructed to compare a stored string value (the password hash) against an integer value (the attacker's payload), it executes an implicit type conversion. MySQL standard behavior dictates that the string must be converted to a numeric type to facilitate the comparison operation.

During this implicit conversion, MySQL parses the string from left to right. If the string does not begin with a numeric character, the entire string evaluates to the numeric value 0. Since most standard password hashes (such as MD5 or bcrypt) frequently begin with alphabetic characters, the stored hash evaluates to 0. The attacker supplies the integer 0 in the payload, causing the database comparison 0 = 0 to return true, which the application interprets as a successful password match.

To understand the mechanical failure, it is necessary to examine the interaction between the application layer and the database layer. The vulnerable implementation of mci_check_login lacked parameter type declarations, allowing mixed data types to propagate. The database abstraction layer then constructed the query utilizing the unmodified integer, creating the condition for the type-juggling flaw.

The remediation, implemented in commit b349e5c890eeda9bd82e7c7e14479853f8a30d9f, resolves the vulnerability by enforcing strict type boundaries at the function definition. The patch introduces explicit parameter type hinting for the mci_check_login function.

// Pre-patch vulnerable implementation
function mci_check_login( $p_username, $p_password ) {
    // ... type evaluation deferred to database
}
 
// Post-patch secure implementation
function mci_check_login( ?string $p_username, ?string $p_password ) {
    $p_username ??= '';
    $p_password ??= '';
    // ... execution continues with guaranteed string types
}

By defining the parameter as a nullable string (?string), PHP automatically coerces the incoming integer 0 into the string value "0" before the function block executes. When this string value is passed to the database, MySQL compares the stored hash string against the literal string "0". Since both operands are strings, no implicit type conversion occurs, the comparison correctly evaluates to false, and the authentication attempt fails.

Exploitation of CVE-2026-30849 requires minimal prerequisites. The attacker must possess network line-of-sight to the MantisBT SOAP endpoint, typically located at /api/soap/mantisconnect.php. The attacker must also identify a valid username for the target system, which is commonly achieved by targeting the default administrator account or enumerating usernames via application metadata.

The attack methodology involves constructing a specifically formatted XML payload. The attacker crafts a valid SOAP envelope requesting an action that requires authentication, such as mc_project_get_id_from_name. Within the authentication parameters of the XML request, the attacker modifies the password node to explicitly declare an integer type.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:man="http://futureware.biz/mantisconnect">
   <soapenv:Header/>
   <soapenv:Body>
      <man:mc_project_get_id_from_name>
         <username>administrator</username>
         <password xsi:type="xsd:int">0</password>
         <project_name>Internal Project</project_name>
      </man:mc_project_get_id_from_name>
   </soapenv:Body>
</soapenv:Envelope>

Upon transmitting this payload to the vulnerable endpoint, the server processes the authentication block. The type coercion flaw results in a successful login context for the administrator account. The server then executes the requested SOAP action under the context of that privileged user, returning the requested data or confirming the state modification.

The security impact of CVE-2026-30849 is severe, accurately reflected in its CVSS 4.0 Base Score of 9.3. The vulnerability provides an unauthenticated attacker with an immediate, deterministic mechanism to bypass all primary authentication controls. The exploit is completely reliable and does not depend on memory corruption, timing conditions, or complex exploitation chaining.

Once authenticated, the scope of the attacker's authorization depends entirely on the privileges associated with the compromised account. If the targeted account holds administrative rights, the attacker gains complete functional control over the MantisBT environment. This allows for the exfiltration of sensitive vulnerability data, modification of bug reports, and manipulation of user accounts.

The flaw strictly impacts the confidentiality and integrity of the application data, scoring high in both CVSS metrics (VC:H, VI:H). Availability is scored as low (VA:L), as the attacker could theoretically delete application data or disable accounts, but the vulnerability does not directly facilitate resource exhaustion or service crashes. The attack requires no user interaction (UI:N) and no prior privileges (PR:N).

The definitive remediation for CVE-2026-30849 is upgrading the MantisBT installation to version 2.28.1 or a subsequent secure release. The maintainers have integrated comprehensive type enforcement across the SOAP API interfaces, neutralizing the root cause of the vulnerability. Administrators should prioritize deployment of this patch on all internet-facing instances.

Organizations operating legacy environments that cannot be immediately patched must implement compensating controls. The primary recommended workaround is to disable the SOAP API entirely. This is achieved by modifying the main MantisBT configuration file (config_inc.php) and appending the directive $g_enable_soap = OFF;. This action terminates the vulnerable application attack surface.

As an additional layer of defense-in-depth, security teams can deploy Web Application Firewall (WAF) rules to inspect incoming SOAP traffic. The WAF can be configured to block any XML requests directed at the /api/soap/mantisconnect.php endpoint containing the string pattern xsi:type="xsd:int" within a password tag block. While effective as a temporary measure, WAF rules should not substitute for the application-level patch.