A recently disclosed exploit demonstrates how an unauthenticated request can reach PHP’s eval() function within vBulletin, enabling code execution on unpatched forum servers. This attack requires no user account, administrative access, or user interaction.
According to SSD Secure Disclosure, vBulletin versions 6.2.1 and earlier, as well as 6.1.6 and earlier, are affected. However, a specific lower version boundary is not provided. vBulletin released security patches for versions 6.2.1, 6.2.0, and 6.1.6 at the end of June, followed by the release of version 6.2.2 on July 1, nearly four weeks before the public disclosure of the exploit.
Administrators managing self-hosted installations are advised to apply the appropriate patch for their version or upgrade to 6.2.2. vBulletin has confirmed that its Cloud sites have already been patched against this vulnerability.
As of July 27, 2026, there have been no reports of active exploitation, and CVE-2026-61511 is not listed in CISA’s Known Exploited Vulnerabilities catalog. SSD has published an interactive proof-of-concept; however, the script contains a minor error—a letter where a digit should be—that prevents it from running unchanged. This error is trivial to correct and does not affect the underlying vulnerability.
The public record does not clarify whether the flaw was exploited during the approximately four weeks between the late-June patch release and the July 27 disclosure, as neither SSD’s advisory nor vBulletin’s notices address this period.
SSD’s technical analysis identifies this issue as CVE-2026-61511, an unauthenticated remote code execution flaw in vBulletin’s template engine. At the time of writing, there is no official severity score available, as the National Vulnerability Database ceased routinely enriching new CVEs with CVSS scores earlier this year.
The vulnerable code resides in /includes/vb5/template/runtime.php, within the vB5_Template_Runtime::runMaths() method, which handles inline math in templates. This function strips characters outside a restricted set and then passes the remaining input directly to eval(). The filter blocks letters but permits digits, parentheses, concatenation, arithmetic operators, and binary operators such as XOR. This allows for the reconstruction of PHP strings and callable function names without any letters, using a restricted-character technique referred to as “phpfuck.”
Exploiting this vulnerability does not require access to the admin panel. vBulletin renders templates over a public route, ajax/render/pagenav, and the default pagenav template copies a visitor-supplied pagenav[pagenumber] value into a {vb:math} tag, which then passes it to runMaths(). This chain transforms a template bug into pre-authentication remote code execution; SSD’s proof-of-concept uses it to reconstruct PHP’s system function and execute an operating-system command, returning the output in the HTTP response.
Our reproduction of the disclosed filtering and evaluation logic confirmed the reported error. With the typo corrected, a harmless strlen() test payload executed; without the correction, the allowlist stripped the stray letter, resulting in syntactically invalid PHP. This test confirmed the expression-building flaw but did not constitute a complete attack against a live vBulletin server.
While the exploit’s banner refers to the issue as a zero-day, the vendor’s patches and the 6.2.2 release preceded public disclosure by nearly four weeks. The exploit code is new; however, the flaw it targets was already addressed. With Cloud reportedly patched and self-hosted fixes available for nearly a month, the current risk is primarily concentrated in self-hosted, internet-facing vBulletin installations that have not yet applied the updates.
This situation underscores the critical importance of timely patch management. Even when patches are available, unpatched systems remain vulnerable, especially once exploit details become public. Administrators should prioritize applying security updates promptly to mitigate potential threats.
