vBulletin RCE exploit went public: get to 6.2.2 today

If you still run a vBulletin forum — a customer community, a dealer portal, the support board somebody set up in 2014 — today is the day it moves to the top of the list. A working exploit for CVE-2026-61511, an unauthenticated remote code execution flaw in vBulletin's template engine, was published on July 27, roughly four weeks after the fix shipped. There are no confirmed in-the-wild attacks yet. That is the entire value of reading this today.

What actually happened

The Hacker News reports that SSD Secure Disclosure published a proof-of-concept for the flaw, credited to researcher Egidio "EgiX" Romano — who disclosed a related vBulletin template-engine bug in 2025.

The bug itself is an old-school PHP classic. In /includes/vb5/template/runtime.php, the vB5_Template_Runtime::runMaths() method strips characters outside a restricted set and then passes whatever survives straight to eval(). Restricted-character filtering is not a sandbox: attackers can reconstruct callable PHP functions without using letters at all, and the filter waves it through. The result is code execution on your server with no authentication.

Affected versions: vBulletin 6.2.1 and earlier, and 6.1.6 and earlier. vBulletin shipped patches in late June and released 6.2.2 on July 1, 2026. Note there's no NVD severity score to anchor on — NVD stopped routine CVSS enrichment earlier this year. Don't wait for a number. Unauthenticated RCE is the number.

As of publication the CVE is not in CISA's Known Exploited Vulnerabilities catalog and nobody has confirmed active attacks. Public PoC plus a widely deployed PHP forum plus trivially scannable version strings is not a combination that stays quiet.

Why patching self-hosted software matters for your business

The reason this one is dangerous isn't technical. It's organizational. Nobody owns the forum.

Self-hosted community software has a specific decay pattern in small businesses: it gets installed to solve a real problem, it works, the person who installed it leaves, and it keeps serving pages for a decade on a box that isn't in anyone's patch rotation. It usually shares a server — or at minimum a network — with things that do matter. Post-exploitation, an attacker doesn't care that the forum is low-value. They care that they're now inside, with a PHP shell, reading your database credentials.

The concrete work, in order:

1. Find it. Check the footer or /core/vb_version.php for a version string. If you're not sure whether you run vBulletin anywhere, that uncertainty is the actual finding.
2. Patch to 6.2.2 or later. If you're on 6.1.x and can't jump majors, apply the 6.1.6 security patch from the vendor announcement.
3. Assume the four-week gap mattered. The patch closed in late June; you're finding out now. Check for PHP files with recent modification times outside your normal deploy path, unexplained admin accounts, and outbound connections from the web host.
4. Decide whether you still need it. Half the vBulletin installs we've found in audits had under a dozen active users. A read-only static archive has no eval() in it.

The pattern generalizes past this CVE. Anything self-hosted — forum, wiki, ticketing tool, internal dashboard — needs a named owner and a version you can query. Vendor auto-update doesn't apply here. You patch it or nobody does.

Sources: The Hacker News, vBulletin security patch announcement.