vBulletin Ships Emergency Patch for Critical Pre-Auth RCE — PoC Is Public, 5.x Branch Is Abandoned

On June 25, 2026, independent researcher Egidio Romano reported a critical pre-authentication remote code execution flaw in vBulletin through SSD Secure Disclosure. On July 1, vBulletin 6.2.2 shipped the fix. On July 28, the proof-of-concept exploit went public. The window is closed: every internet-facing vBulletin instance without Patch Level 1 is now a live target.

An eval() RCE that bypasses sanitization

CVE-2026-61511 is a pre-auth remote code execution vulnerability affecting the 5.x branch (up to 5.7.5) and the 6.x branch (up to 6.2.1) of the proprietary PHP forum engine.

The root cause sits in the runMaths() function, designed to evaluate mathematical expressions inside templates. This function passes user-controlled input to PHP’s eval() construct without adequate sanitization. By sending a specially crafted request to the ajax/render/[template] endpoint, an unauthenticated attacker can route arbitrary PHP code through a vulnerable template — specifically pagenav — and execute system commands on the server.

The sanitization layer that vBulletin applies is defeated using a technique called “phpfuck”, an obfuscation method that escapes input filters by using only characters valid in PHP expression context. SSD Secure Disclosure published a full technical analysis alongside a working exploit targeting the ajax/render/pagenav route.

Researcher Egidio Romano has a track record with vBulletin. In May 2025, two critical flaws he also discovered were exploited at scale within days of PoC publication, triggering automated scanning waves against unpatched instances. The pattern is well established, and this time the stakes are higher because of the 5.x decision.

vBulletin’s vulnerability history: a recurring pattern

CVE-2026-61511 is not an isolated incident. The vBulletin codebase has accumulated a troubling collection of critical RCE flaws over the past decade, many of them rooted in the same pattern: unsanitized input reaching PHP’s dynamic code execution primitives.

In 2019, CVE-2019-16759 (CVSS 9.8) allowed unauthenticated attackers to achieve RCE through the ajax/api/ routing layer. The exploit chain was trivial — a single POST request. In 2020, CVE-2020-17496 (CVSS 9.8) targeted the same ajax/render/ endpoint family with a widget configuration injection. By May 2025, Romano had already disclosed two additional pre-auth RCE flaws through SSD, and both saw active exploitation within 48 hours of public disclosure.

The common denominator across all these vulnerabilities is the template rendering engine. vBulletin’s architecture relies on a custom PHP template system that pre-dates modern sandboxing practices. Every template that accepts user-controlled parameters is a potential entry point, and the eval()-based expression evaluator amplifies every sanitization mistake into a full system compromise.

Patch Level 1 for 6.x, no lifeline for 5.x

vBulletin 6.2.2, released July 1, 2026, addresses CVE-2026-61511. Backported fixes labeled Patch Level 1 are available for versions 6.2.1, 6.2.0, and 6.1.6.

The picture is starkly different for the 5.x branch. Wayne Luke, vBulletin’s technical support lead, stated on the project’s official forums that users of older versions need to “upgrade to a newer release.” Translation: no patch will ever be issued for the 5.x branch.

This decision leaves thousands of instances in an impossible position. The 5.x branch, while aging, still powers active communities — gaming forums, technical support portals, automotive enthusiast boards, and specialized discussion platforms. These sites are now structurally vulnerable to an unauthenticated RCE with a public proof of concept.

vBulletin’s long shadow over community web

Launched in 2000, vBulletin was the gold standard of online forums for over a decade. It powered some of the largest web communities through the 2000s and early 2010s. While the market has since fragmented — Discourse, XenForo, Flarum, and platforms like Discord have peeled away segments — vBulletin retains a significant install base.

Hard adoption figures are elusive: Internet Brands, vBulletin’s parent company, does not publish deployment statistics. But Shodan searches for vBulletin signatures still return tens of thousands of exposed instances. A non-trivial fraction of those run the 5.x branch.

A compromised vBulletin instance is more than a defaced forum. It hands an attacker a user database — emails, hashed passwords, private messages, connection logs. It also provides a foothold: the web server becomes a pivot point for lateral movement into the broader infrastructure. For organizations like CISA and ANSSI that track critical infrastructure dependencies, legacy forum software sitting on the same network segment as internal tools is a recurring nightmare.

Detection and immediate response

For affected administrators, the path forward is binary: patch or migrate. There is no configuration workaround.

If you run vBulletin 6.x

Apply the Patch Level 1 that matches your version. Packages are available through the vBulletin member portal. The update is straightforward and requires no database migration.

# Check installed version
grep "define('VB_VERSION'" /var/www/vbulletin/includes/version_vbulletin.php

# After applying the patch, verify Patch Level 1 is shown
grep "PATCH_LEVEL" /var/www/vbulletin/includes/version_vbulletin.php

If you run vBulletin 5.x

You need to plan a migration to vBulletin 6.2.2+ or an alternative platform. In the interim, these mitigations reduce the attack surface without eliminating it:

• Place the admin panel and member area behind a VPN or additional HTTP authentication.
• Block access to the /ajax/render/ endpoint at the reverse proxy level (nginx, Apache). This breaks some template functionality but neutralizes the known attack vector.
• Enable a WAF with a rule targeting POST requests to ajax/render/ containing suspicious PHP patterns (eval, system, exec, backticks).
• Monitor access logs for requests to /ajax/render/pagenav. Exploitation attempts leave an identifiable HTTP signature.

# Example nginx rule to block the vulnerable endpoint
location ~ ^/ajax/render/ {
    deny all;
}

These measures are temporary. With the PoC now public, automated scanners will target this endpoint within days — if they are not already doing so. The only durable solution is an upgrade.

Verdict

CVE-2026-61511 checks every box for a worst-case vulnerability: pre-authentication, direct RCE, public PoC, and an entire major branch left unpatched. The May 2025 precedent — where two similar vBulletin flaws triggered mass exploitation campaigns within 48 hours of PoC publication — leaves no ambiguity about what comes next.

If your instance runs vBulletin 6.x, apply Patch Level 1 today. If it runs vBulletin 5.x, you do not have a patch to apply — you have a migration to execute. Prioritize it before the scanners do it for you.

Historically, vBulletin RCE flaws have been weaponized by ransomware affiliates and cryptominers alike. The timeline from public PoC to mass scanning is measured in hours, not days — and Shodan queries for the ajax/render/ endpoint are already circulating in security communities.

References

• BleepingComputer — vBulletin fixes critical pre-auth RCE flaw with public exploit (July 28, 2026)
• SSD Secure Disclosure — vBulletin Pre-Auth RCE — technical analysis and PoC
• vBulletin Forums — Announcement: vBulletin 6.2.2 Patch Level 1 Security Release (July 1, 2026)
• Egidio Romano — CVE-2026-61511 technical write-up — detailed analysis by the researcher
• BleepingComputer — vBulletin flaws exploited in the wild (May 2025) — context on previous vBulletin exploitation campaigns