Public exploit raises risk for unpatched vBulletin forums

A critical vBulletin vulnerability has exposed unpatched forum servers to remote takeover through malicious requests that require no login credentials or user interaction.

Tracked as CVE-2026-61511, the flaw allows an unauthenticated attacker to inject code into vBulletin’s template-processing system and execute arbitrary PHP commands on the underlying server. Successful exploitation could enable intruders to steal data, modify forum content, install malware, create backdoors or use the compromised machine to attack other systems.

The vulnerability affects vBulletin 5. x versions through 5.7.5 and vBulletin 6. x versions through 6.2.1. Administrators operating older installations have been urged to treat their systems as potentially exposed unless they can confirm that the appropriate security update has been applied.

Technical details and a proof-of-concept exploit became public on July 27, increasing the likelihood that attackers will scan the internet for vulnerable forums. The release came several weeks after vBulletin issued security patches for supported versions 6.2.1, 6.2.0 and 6.1.6 on June 30. Version 6.2.2, which incorporates the correction, was released on July 1.

The flaw is located in the runMaths() method of the vB5TemplateRuntime component. That function processes mathematical expressions contained within forum templates but passes attacker-controlled input to PHP’s eval() function without sufficient validation.

An attacker can reach the vulnerable function through the publicly accessible ajax/render/pagenav route. A crafted value supplied through the pagenav[pagenumber] parameter is inserted into a {vb:math} template tag and passed to the affected method.

Because this route is available before authentication, an attacker does not need a forum account, administrator privileges or access to the control panel. The malicious request can be sent directly to the web application over the internet.

PHP’s eval() function executes a supplied string as PHP code. Its use with improperly filtered external input creates a severe security risk because the application may interpret attacker-controlled characters as executable instructions rather than ordinary data.

The disclosed exploit demonstrates how an attacker could reconstruct a PHP command-execution function and run operating-system commands on the server. Although the published demonstration contains a minor typographical defect that prevents it from operating unchanged, the technical path is clear enough for capable attackers to reproduce.

No confirmed attacks exploiting CVE-2026-61511 had been publicly identified by July 27. The vulnerability was also absent from the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalogue at that point. The availability of exploit details, however, sharply reduces the time required for threat actors to develop working attack tools.

Remote code execution vulnerabilities are particularly dangerous because a successful intrusion can extend beyond the forum application. The level of access obtained depends on the permissions assigned to the web server process and the security controls surrounding the installation.

An attacker may be able to read database credentials stored in configuration files, access private messages, obtain email addresses, alter user records or inject malicious scripts into forum pages. Compromised servers could also be incorporated into botnets, used for cryptocurrency mining or employed as staging points for phishing and malware campaigns.

Forum operators running supported vBulletin 6 branches should upgrade to version 6.2.2 or later. Administrators unable to complete a full upgrade immediately should install the security patch supplied for their current supported release.

Older vBulletin 5 installations require particular attention because the vendor’s June patch announcement focused on maintained 6. x releases. Operators should verify available upgrade paths and avoid assuming that an unsupported version is safe merely because it was not named in the original patch notice.

Security teams should examine web access logs for unusual requests to the page-navigation rendering endpoint, especially requests containing malformed or heavily encoded pagenav[pagenumber] values. Unexpected child processes launched by the web server, newly created PHP files, altered templates and unexplained administrator accounts may indicate compromise.

Administrators should also review file-integrity alerts, outbound network connections and scheduled tasks. Applying a patch will prevent new exploitation but will not remove a backdoor or malicious account planted before the update.