Ask an unpatched vBulletin forum for page two of a thread, and the number you send it can be PHP code that the server runs. No account, no login, no password.
That is CVE-2026-61511, found by Egidio Romano, who publishes as EgiX at Karma(In)Security and reported it through SSD Secure Disclosure. Romano's advisory KIS-2026-13 went public on 27 July, and includes proof of concept code. It affects vBulletin 5.x up to and including 5.7.5, and 6.x up to and including 6.2.1.
VulnCheck, which assigned the scores in the NVD record, rates it 9.3 critical on CVSS v4.0 and 9.8 on CVSS v3.1. Unauthenticated code execution on a public web server is about as high as that scale goes.
A page number that reaches eval()
The bug sits in a small helper called runMaths(), inside the file that renders vBulletin templates. Its job is to evaluate arithmetic written into a template, so it hands the expression to PHP's eval() function, which executes whatever it is given. Before doing that it runs the input through a regular expression meant to keep anything that is not arithmetic out.
According to Romano's analysis, that filter strips everything except digits, parentheses, mathematical operators and binary operators, the XOR operator among them. That sounds restrictive. It is not quite restrictive enough. Those characters are sufficient to compose arbitrary PHP a piece at a time, a well documented technique for building working code out of a deliberately tiny alphabet, and what survives the filter still reaches eval().
An administrator could always trigger it by editing a template and adding a crafted math tag, which would not be much of a vulnerability. The reason this one matters is the unauthenticated route Romano identified: the ajax render endpoint will render a template on request, and vBulletin's default page navigation template feeds a user supplied page number straight into a math tag. Send your PHP as that page number and it lands in eval() with nobody having logged in.
Nobody has confirmed attacks, but the odds are unusual
CISA has not added CVE-2026-61511 to its Known Exploited Vulnerabilities catalog, checked against the 25 August edition, so there is no public confirmation of exploitation in the wild. What there is instead is a forecast. FIRST's Exploit Prediction Scoring System, which estimates the probability that a vulnerability will see exploitation activity in the next 30 days, put this one at 0.71 on 25 August, in the 99.3rd percentile of all scored vulnerabilities. Fewer than one in a hundred sit that high.
That is a model output, not evidence, and it should be read as one. But the ingredients behind it are plain enough: an internet facing forum platform, no authentication required, and a full technical write up with exploit code that anyone can read. Public exploit code moves a vulnerability from theoretical to operational quickly, which is what made the Metabase zero day so urgent earlier this month.
Patched since June, so check your version
vBulletin shipped a security patch on 30 June and released version 6.2.2 on 1 July, both before the flaw was described publicly. The fix is to apply the vendor patch or move to 6.2.2 or later. Romano's disclosure timeline shows the vendor was notified on 25 June and patched inside a week, which is a creditable turnaround.
The gap now is not the vendor's. It is the long tail of forums nobody has logged into the admin panel of in years, which is the same tail that keeps catching out self hosted software: an unattended WordPress plugin flaw earlier this month needed a forced mass update for exactly that reason. A forum that has been quietly running since 2019 is still a PHP server on the public internet, and it is still yours.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.