CVE-2026-45119 in MyBB
Summary
by MITRE • 08/18/2026
MyBB is free and open source forum software. Prior to 1.8.40, the Admin CP UTF-8 Conversion module does not validate certain requests correctly, allowing same-site attackers to alter table encoding and deny service with a specially crafted URL. The do=all control flow in admin/modules/tools/system_health.php performs ALTER TABLE operations, column rewrite phases, and fulltext index rebuilds on GET requests for the database table named by the table parameter without request verification. The uniquely identifying implementation details include GET requests without request verification. This issue is fixed in version 1.8.40.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in MyBB versions prior to 1.8.40 represents a critical failure in server-side input validation within the administrative control panel, specifically affecting the UTF-8 Conversion module. As an open-source forum software widely deployed across various web environments, MyBB relies on robust access controls and request verification mechanisms to protect sensitive database operations from unauthorized modification. The core technical flaw resides in the file admin/modules/tools/system_health.php, where the do=all parameter triggers a sequence of high-privilege administrative actions including ALTER TABLE statements, column rewrite phases, and fulltext index rebuilds. Crucially, these destructive operations are executed in response to GET requests without any form of request verification or integrity checks. This architectural oversight allows an attacker who can trick an administrator into visiting a specially crafted URL to trigger database schema modifications remotely via the browser's automatic handling of GET requests.
From a technical perspective, this vulnerability is classified as CWE-352 Cross-Site Request Forgery because it exploits the trust that a web application has in user agents from specific origins without verifying whether the submission was intentionally made by that user. The attacker does not need to bypass authentication directly but rather leverages the authenticated session of an administrator who logs into the MyBB admin panel. By constructing a malicious URL containing parameters such as table=specific_table and do=all, the attacker forces the browser to send this request while the administrator is logged in. Since GET requests are typically considered safe and idempotent by many frameworks, they often bypass CSRF tokens or other anti-CSRF protections that might be applied to POST requests. The lack of validation on the table parameter further exacerbates the risk, allowing potential manipulation beyond just triggering the conversion process if additional injection vectors were present in related code paths.
The operational impact of this vulnerability is severe and primarily centers around denial of service through data corruption or structural damage. By altering the encoding of database tables via ALTER TABLE operations without proper authorization checks, an attacker can render forum data unreadable or cause SQL errors that disrupt normal site functionality. In some scenarios, improper handling of column rewrites and index rebuilds could lead to permanent loss of configuration settings or user data integrity issues if the conversion process fails midway due to malicious input manipulation. This effectively denies service to legitimate users who rely on the forum for communication, requiring manual database intervention by system administrators to restore correct table encodings and indexes. The ability to trigger these operations remotely means that even a single click from an unsuspecting administrator can compromise the stability of the entire platform.
Mitigation strategies must focus on immediate patching and enhanced security configurations. Administrators running MyBB versions prior to 1.8.40 should upgrade to version 1.8.40 or later, where this issue has been resolved through improved request validation mechanisms. In addition to upgrading, implementing strict Content Security Policy headers can help mitigate the risk of CSRF attacks by restricting which origins are allowed to submit forms and execute scripts. Enabling anti-CSRF tokens for all administrative actions, particularly those involving database schema changes, is essential even if they were previously omitted due to perceived low risk with GET requests. Furthermore, limiting access to the admin control panel through IP whitelisting or multi-factor authentication adds layers of defense that reduce the likelihood of an attacker successfully tricking an administrator into executing malicious URLs. Regular security audits and code reviews should also be conducted to identify similar patterns where sensitive operations are exposed via insecure HTTP methods without adequate verification.