vBulletin, one of the longest-running forum platforms on the web, has patched a critical vulnerability that lets an attacker run commands on the server without logging in at all — and working exploit code for it is now public. Tracked as CVE-2026-61511 and rated 9.8 out of 10 in severity, the flaw sits in a template function called runMaths(), which evaluates the arithmetic behind vBulletin's page-navigation display. The function is meant to only accept digits and basic math symbols before handing the result to PHP's eval(), but researcher Egidio Romano found a way to smuggle attacker-controlled code past that filter through the forum's page-navigation endpoint — no account, password, or special access required.
The bug affects vBulletin 5.x up to version 5.7.5 and 6.x up to 6.2.1. It was reported to vBulletin in late June, and version 6.2.2, released 1 July, closes the hole; the vendor also backported the fix to 6.2.1, 6.2.0 and 6.1.6 as a "Patch Level 1" update. There is no fix planned for the 5.x branch. A proof-of-concept exploit was published on 27 July through SSD Secure Disclosure, and coverage has since spread across BleepingComputer, The Hacker News and several other security outlets. As of this writing there's no confirmed evidence of exploitation in the wild — but a public, working exploit against a known-vulnerable, internet-facing platform tends not to stay theoretical for long.
What this means for your business
- If you run a vBulletin forum, check the version today. Community forums, product support boards and member portals built on vBulletin are common and often outlive whoever originally set them up. Confirm which version yours is running before assuming it's "probably fine."
- On 6.x, update to 6.2.2 (or the matching Patch Level 1 backport) now. This isn't a next-sprint patch — pre-auth remote code execution means an attacker needs nothing from you except your forum's public URL.
- On 5.x, there is no fix coming. Treat that branch as end-of-life for this issue: start planning a migration to a supported version or platform, and in the meantime restrict or firewall access to the affected endpoint if your host allows it.
- "No confirmed attacks yet" is not the same as "safe." Public exploit code against a widely deployed platform typically shortens, not lengthens, the runway before real attacks start. Don't wait for a breach notice to be the trigger to patch.
- A platform nobody currently "owns" is the real risk. Forums, wikis and other community software are exactly the kind of system that gets installed once and forgotten. If you can't quickly say who's responsible for patching yours, that's worth fixing independently of this specific CVE.
None of this requires the forum to be your main product. A support community or member site bolted onto an otherwise unrelated business is still a door into your systems if it's left unpatched.