A public proof-of-concept for an unauthenticated remote code execution flaw in vBulletin landed on July 27, exposing forum administrators who skipped last month’s patch cycle. The vBulletin RCE vulnerability, tracked as CVE-2026-61511, lets an attacker run arbitrary PHP on the server without logging in, and the exploit chain needs nothing more than a crafted page number.
What the vBulletin RCE vulnerability actually does
The bug sits in vB5_Template_Runtime::runMaths(), a method inside /includes/vb5/template/runtime.php that evaluates the math expressions behind vBulletin’s {vb:math} template tag. Before handing a value to PHP’s eval(), the method strips it down with a regular expression meant to allow only digits, parentheses and arithmetic operators, including XOR.
That filter is the whole problem. Digits, parentheses and operators are enough to build working PHP through a technique researchers call “phpfuck”: constructing function calls and executable logic entirely out of punctuation and numbers, with no letters for a blocklist to catch. According to a technical writeup analysed by CybersecurityNews, the allowed character set is exactly wide enough to pull this off inside eval().
The path to that code doesn’t need a login. vBulletin’s pagenav template reads a pagenav[pagenumber] value straight from the request, assigns it to a template variable, and later folds it into a math expression that reaches runMaths(). An attacker just posts that value to the public ajax/render/pagenav route and the server does the rest.
Who’s affected, and since when
NVD’s entry for CVE-2026-61511 scores the flaw 9.8 on CVSS 3.1 and 9.3 on CVSS 4.0, both critical, and files it under CWE-95, improper neutralisation of directives in dynamically evaluated code. NVD’s version range spans vBulletin 5.0.0 through 6.2.1, though the practical cutoff most write-ups cite is 6.2.1 and earlier, plus 6.1.6 and earlier on the older branch. vBulletin 6.2.2 is not affected.
The vendor moved before the exploit went public. Patches for 6.2.1, 6.2.0 and 6.1.6 shipped in late June, and vBulletin rolled a fully fixed 6.2.2 release on July 1. Cloud-hosted vBulletin forums were patched centrally by the vendor. Exposure now sits with self-hosted installs that never applied the June or July updates. That’s roughly four weeks between a fix existing and the technical detail going public.
The disclosure and the PoC
SSD Secure Disclosure published the advisory alongside an interactive proof-of-concept on July 27. The PoC carries the signature “EgiX,” the handle of researcher Egidio Romano, who disclosed a comparable vBulletin template-engine bug in 2025. That report also flags a single-character typo in the published exploit, so it won’t fire as posted. The fix is trivial for anyone who actually reads the code, though.
No confirmed in-the-wild exploitation had surfaced as of publication. That’s a thin margin, not a reprieve. An unauthenticated flaw reachable in software running on countless internet-facing forums is exactly the kind of bug mass scanners pick up fast, typo or not, once the underlying logic is public, much like wp2shell’s pre-auth RCE chain in WordPress earlier this month.
What to do now
If your forum runs on self-hosted vBulletin, check the version in the admin control panel first. Anything below 6.2.2 needs the update immediately, and 6.1.x installs that never took the 6.1.6 patch are in the same boat. Cloud customers can confirm with vBulletin support that their instance received the fix, but the vendor has already applied it fleet-wide.
Where an immediate upgrade isn’t possible, a web application firewall rule blocking anomalous characters in the pagenav[pagenumber] parameter buys time. It’s a stopgap, though, not a substitute for patching. Check access logs for repeated or malformed requests to ajax/render/pagenav going back to late June, the window during which the flaw existed unpatched. Undisclosed exploitation during that stretch can’t be ruled out. The same reduce-exposure-while-you-wait logic applied to July’s Fastjson RCE vulnerability, where mitigation had to hold the line before a full fix landed.
Beyond the immediate patch
Forum operators should also treat this vBulletin RCE vulnerability as a prompt to review how their platform handles other template tags that touch eval() or similar dynamic execution paths. Romano’s 2025 finding in the same subsystem suggests the pattern, not just this one function, is worth a second look.
Larger boards running vBulletin behind a CDN or reverse proxy should also confirm that WAF rules actually inspect the request body and query parameters used by ajax/render/pagenav, not just the URL path. A rule that only checks the endpoint name, without looking at the pagenav[pagenumber] value itself, won’t catch a phpfuck-style payload, since nothing about the request looks unusual until you read the parameter contents.
The practical takeaway for anyone managing a self-hosted forum: patch cadence matters more than patch complexity here. This was a straightforward update to apply once released, and the gap between “patch available” and “publicly exploited” is often measured in days once a PoC lands, not weeks. That said, applying the update is only the first step; a recent SANS audit of patched SonicWall firewalls is a reminder to confirm the fix actually took, not just that an update was clicked through.
