CVE-2026-45126 in MyBB
Summary
by MITRE • 08/18/2026
MyBB is free and open source forum software. Prior to 1.8.40, the Admin CP Security Questions module does not validate the anti-CSRF token correctly, allowing same-site attackers to enable or disable registration challenge questions with a specially crafted URL. The controller processes GET requests for the disable and enable actions to modify mybb_questions.active without verifying the my_post_key token attached by the user interface. The uniquely identifying implementation details include admin/modules/config/questions.php. This issue is fixed in version 1.8.40.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/18/2026
MyBB, a widely deployed open-source forum software platform, contains a critical security flaw within its administrative control panel that undermines the integrity of configuration changes related to user registration challenges. Specifically, the Admin CP Security Questions module fails to properly validate anti-CSRF tokens for certain actions, creating an opportunity for same-site attackers to manipulate system settings without proper authorization. This vulnerability affects versions prior to 1.8.40 and centers on the controller logic located in admin/modules/config/questions.php, which handles requests to enable or disable registration challenge questions.
The technical root cause of this vulnerability lies in the incorrect validation mechanism employed by the application when processing GET requests for disabling or enabling security question features. In a secure implementation, state-changing operations such as modifying database records like mybb_questions.active should require POST requests accompanied by a valid anti-CSRF token to ensure that the request originated from an authenticated and legitimate user session within the administrative interface. However, in this flawed implementation, the controller processes GET requests for these actions without adequately verifying the my_post_key token attached by the user interface. This deviation from secure coding practices allows an attacker who can trick an administrator into visiting a maliciously crafted URL to execute unintended commands on behalf of that authenticated session.
The operational impact of this vulnerability is significant because it allows unauthorized modification of critical security configurations. By enabling or disabling registration challenge questions, an attacker can effectively weaken the barrier against automated bot registrations and spam accounts if they disable these challenges, or potentially cause a denial of service by forcing configuration states that disrupt normal user onboarding processes if enabled incorrectly depending on server constraints. Since this action requires administrative privileges to perform legitimately, successful exploitation implies that the attacker has gained some level of influence over an administrator's browser session through social engineering techniques such as phishing links embedded in emails or malicious websites. This represents a classic case where cross-site request forgery protections are bypassed due to improper method and token validation logic.
From a classification perspective, this vulnerability aligns with CWE-352, which describes Cross-Site Request Forgery (CSRF). The failure to verify the anti-CSRF token for state-changing operations is a direct manifestation of this weakness. Furthermore, in terms of tactical mapping within the MITRE ATT&CK framework, this exploit technique falls under T1078, specifically Valid Accounts, as it relies on abusing legitimate administrative credentials through session manipulation rather than credential theft or brute force attacks. It also relates to T1496, Resource Hijacking, if the resulting configuration change leads to increased resource consumption via spam registrations, though the primary vector is unauthorized state modification.
To mitigate this vulnerability and prevent similar issues in future development cycles, it is imperative that all administrative actions that modify system configurations are restricted to POST requests rather than GET requests. Additionally, every such request must be rigorously validated against a unique, session-specific anti-CSRF token before any database updates or configuration changes are applied. Developers should implement strict input validation and ensure that the my_post_key or equivalent security tokens are not only present but also correctly verified against the current user's session data. Upgrading to version 1.8.40 of MyBB resolves this issue by correcting these implementation details in the admin modules, thereby restoring proper access control mechanisms for administrative functions. Organizations running older versions should prioritize immediate patching and review their administrative access logs for any suspicious configuration changes that may have occurred during the window of vulnerability exposure.