A researcher found a way to turn a page number into a working PHP shell — no login required. vBulletin patched it in July. A lot of self-hosted forums haven't.
A researcher just published a complete, working exploit for a vBulletin bug that lets a total stranger run PHP code on your forum — no account, no password, nothing. The alarming part isn't really the bug itself. It's the timing. vBulletin fixed this on July 1, and the proof-of-concept only went public on July 27, as BleepingComputer first reported. If you run a self-hosted vBulletin install and you're not already on 6.2.2 or a Patch Level 1 backport, you've had a month to close this, and the clock on someone finding you just started for real.
How a page number becomes a shell
The flaw lives in vb5/template/runtime.php, in a function called runMaths(). vBulletin's template engine lets forum designers do inline arithmetic with a {vb:math} tag — page 4 of 12, that kind of thing — and runMaths() is what actually evaluates the expression. To do math at all, it hands the expression to PHP's eval(), gated by a filter meant to allow only digits, parentheses and arithmetic operators. That filter also allows XOR. One extra character in an allowlist, and that's the entire vulnerability.
// simplified shape of the bug inside runMaths()
$expr = $_REQUEST['pagenumber']; // reaches ajax/render/pagenav, no login needed
if (preg_match('/^[0-9()+\-*\/^]+$/', $expr)) {
eval('$result = ' . $expr . ';'); // digits + parens + XOR = enough to build arbitrary PHP
}
With digits, parentheses and XOR available, an attacker can bit-shift and self-assemble arbitrary PHP one character at a time — the same 'phpfuck'-style trick that's been used against loosely filtered eval() calls for years. Egidio Romano worked out the full chain, reported it privately on June 25, and published a working proof-of-concept once patches had already shipped. A detailed technical writeup traces the request through the ajax/render endpoint — specifically the pagenav template — and it needs zero authentication to reach.
The bug lets an attacker execute arbitrary PHP on the server — the same class of flaw that's hit several aging web platforms this year. · Unsplash
The patch already exists. That's almost the scarier part.
vBulletin's own cloud-hosted customers got this fixed centrally and never had to lift a finger. The forums actually exposed are the self-hosted ones — installs a volunteer admin stood up years ago and hasn't logged back into since. That's not really a vBulletin-specific problem. It's the same shape of failure behind how wp2shell actually works: an endpoint nobody had re-audited in years, sitting on software that kept quietly running long after anyone was watching it closely. What is wp2shell walked through the WordPress version of exactly this failure mode a few weeks ago — different codebase, same neglect.
Five weeks, private report to public exploit
June 25, 2026
Egidio Romano privately reports the runMaths() eval() flaw to vBulletin.
July 1, 2026
vBulletin ships 6.2.2 with the fix, plus Patch Level 1 backports for 6.2.1, 6.2.0 and 6.1.6.
July 27, 2026
Romano publishes a full working proof-of-concept exploit publicly.
July 31, 2026
No confirmed in-the-wild attacks yet — but installs still on 6.2.1 or older without the backport remain exposed.
What to do if you run vBulletin
Check your version: Admin CP → Site Builder → Product & Version Information.
On 6.x, upgrade to 6.2.2, or apply the Patch Level 1 hotfix if you're stuck on 6.2.1, 6.2.0 or 6.1.6.
On 5.x, there is no patch — vBulletin's guidance is a full upgrade to 6.2.2, not a fix on the old branch.
If you can't patch immediately, block or rate-limit requests to /ajax/render/ at your reverse proxy or WAF.
Check access logs for POST requests to ajax/render/pagenav carrying long, arithmetic-looking payloads — that's the exploit's signature.
vBulletin RCE: quick answers
Do I need to do anything if my forum is on vBulletin Cloud?
No — vBulletin patched its own hosted customers centrally in early July. This only affects self-hosted installs that manage their own updates.
Is CVE-2026-61511 being exploited right now?
As of July 31, no security outlet has confirmed active exploitation, and it isn't yet on CISA's Known Exploited Vulnerabilities list. A public working exploit existing without confirmed attacks is exactly the window where mass scanning tends to start, though.
Can I just patch this later?
Not really — pre-auth RCE with a public proof-of-concept is about as bad as web vulnerabilities get. Automated scanners typically pick up published exploits within days, sometimes hours.
What if I'm still on vBulletin 5.x?
There's no fix coming for 5.x. vBulletin's position is that 5.x installs should upgrade to 6.2.2 outright, not wait for a backport that isn't happening.
The uncomfortable pattern across this year's worst web exploits — this one, wp2shell, a string of WordPress plugin bugs — is the same: old software, an endpoint built for a convenience feature, and a filter someone thought was tight enough. It rarely is. If you're responsible for a self-hosted anything right now, running through whether you're actually patched is worth ten minutes today, not next month. The Hacker News' coverage is a good place to watch for updates if exploitation is confirmed.
