Skip to content

GHSA-v84x-qvhg-f36r CVE-2026-49273

MantisBT: Remote Code Execution via eval() Class Hoisting in adm_config_set.php

High Packagist
Severity
0.0 / 10
High · CVSS 4.0
Exploit chance (EPSS)
—
No score published
Known exploited
No
Not in CISA's catalog
Weakness
CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
Fix
2.28.4
Upgrade mantisbt/mantisbt to this version or later

Description

MantisBT 2.28.3 and earlier contains a remote code execution vulnerability in the admin "Manage Configuration" feature (adm_config_set.php). When setting a configuration value with a non-string type (integer, float, complex), the value is passed through ConfigParser -> Tokenizer, which calls eval() with a return; prefix intended to prevent code execution.

However, PHP hoists function and class declarations at compile time, even past a return statement. An attacker can define a class in the eval()'d code that hijacks a class loaded later via PHP's autoloader, achieving arbitrary code execution.

This vulnerability requires administrator access to the web UI (adm_config_set.php). The REST API's ConfigsSetCommand does NOT use Tokenizer/eval() and is not affected.

Impact

  • Remote code execution as the web server user (www-data) from an authenticated administrator session

Patches

Workarounds

None.

Resources

Credits

McCaulay Hudson (@_McCaulay) of watchTowr

Affected versions

Packagist

PackageVulnerableFixed in
mantisbt/mantisbt
>= 1.3.0, < 2.28.4
2.28.4

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

mantisbt/mantisbt Packagist → 2.28.4

composer
composer require mantisbt/mantisbt:^2.28.4

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
High
User interaction
None
Confidentiality (vulnerable system)
High
Integrity (vulnerable system)
High
Availability (vulnerable system)
High
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

Weakness

CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").

How to prevent it
  • Architecture and Design, Implementation: If possible, refactor your code so that it does not need to use eval() at all.
  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
  • Implementation: For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

References

Timeline

  1. Published
  2. Last updated by the source
AdvisorySeverityWhy it's related
GHSA-h2wf-967x-gxvw
MantisBT: Stored XSS in print_all_bug_page_word.php
High Also affects mantisbt/mantisbt
GHSA-4vpf-w7qv-5h3q
MantisBT: Injection of TIME_TRACKING and REMINDER Notes via REST and SOAP APIs
Medium Also affects mantisbt/mantisbt
GHSA-3v2j-6fw9-f57c
MantisBT: REST and SOAP API Issue Update Accepts Unreleased Product Versions From Updaters
Medium Also affects mantisbt/mantisbt
GHSA-vcrw-4xvv-jh49
MantisBT: Reflected XSS in admin/install.php via unescaped printf
Critical Also affects mantisbt/mantisbt
GHSA-77x8-3v3h-hrhv
MantisBT: Reflected XSS in admin/install.php
Critical Also affects mantisbt/mantisbt
GHSA-m7ph-9558-mrx3
MantisBT: REST API unauthorized Issue status change
Medium Also affects mantisbt/mantisbt
GHSA-c2xg-qjqw-2v98
MantisBT: SOAP API Authentication Bypass with Privilege Escalation to Administrator
Critical Also affects mantisbt/mantisbt
GHSA-mw6p-33vw-46cc
MantisBT: SQL Injection via history_order Configuration Value
High Also affects mantisbt/mantisbt
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor