# vBulletin's eval() Problem Is Back — And This Time There's a Working Exploit
A critical pre-authentication remote code execution flaw in vBulletin has gone public with a working proof-of-concept, and the clock is now running for every forum still on an unpatched version. CVE-2026-61511 lets an anonymous attacker send a crafted HTTP request to a publicly accessible endpoint and get a shell. No credentials. No social engineering. Just a request.
This is about as bad as it gets for production web software.
## The Technical Core: eval() Trusted Math It Shouldn't
The root cause lives inside runMaths(), a function that was presumably designed to safely evaluate mathematical expressions inside vBulletin's template engine. The operative word is "presumably." In practice, it passes user-supplied input to PHP's native eval() function without adequate sanitization — and PHP's eval() doesn't know or care whether you're computing an equation or executing arbitrary system commands.
The attack path is clean: send a crafted request to /ajax/render/[template], target a vulnerable template such as pagenav, and let vBulletin's own rendering pipeline carry your payload into eval(). What comes out the other side is code execution as whatever user PHP is running under.
SSD Secure Disclosure's published technical analysis reveals the sanitization bypass uses a technique known informally as "phpfuck" — a creative obfuscation method that mutates PHP code into a form that clears the insufficient input filters while remaining syntactically valid when eval() processes it. The published PoC targets the ajax/render/pagenav route specifically, executes arbitrary system commands, and is now publicly available to anyone motivated enough to search for it.
## Version Coverage and the 5.x Abandonment Problem
Affected versions span both major branches: the 5.x line up through 5.7.5 and the 6.x line up through 6.2.1. The fix is version 6.2.2, released July 1 — a creditably fast six-day turnaround from Romano's June 25 disclosure. Security patches were also backported to v6.2.1, v6.2.0, and v6.1.6 as "Patch Level 1" releases.
What isn't getting fixed: everything in the 5.x branch.
vBulletin's technical support lead Wayne Luke made clear on the project's forums that users on older versions need to upgrade to a supported release. Translation: if you're running vBulletin 5.x, this vulnerability will not be patched for your version, and the company is telling you the migration is your problem to solve. Given the operational overhead of upgrading major forum versions — database migrations, plugin compatibility, theme rebuilds — a meaningful percentage of 5.x installs will still be running vulnerable code months from now.
## The Same Researcher. Again.
Egidio Romano, the independent researcher who found CVE-2026-61511 and reported it through SSD Secure Disclosure, is not a newcomer to vBulletin's codebase. He also discovered two critical vBulletin flaws disclosed in May 2025 — flaws that threat actors moved to exploit almost immediately after PoCs became public. The pattern here is worth naming: this isn't random researchers stumbling across bugs. Someone has been doing sustained, deep work on vBulletin's internals and repeatedly finding critical issues that should not exist in mature, commercial forum software.
That says something about the state of vBulletin's secure development practices.
## Who's Actually Exposed
vBulletin's community spans gaming sites, automotive enthusiasts, tech discussion boards, and support portals. These aren't Fortune 500 companies with dedicated security teams monitoring their web server logs. They're often small operations run by enthusiasts or community volunteers — the kind of organizations least likely to be watching vulnerability feeds and fastest to let patch cycles slip.
The consequences of a compromise here aren't abstract. A fully unauthenticated attacker with code execution on a forum server can harvest credentials from the database, pivot to hosting infrastructure, inject malware into community downloads, and exploit years of private message history. For any forum that does single sign-on or shares infrastructure with adjacent services, the blast radius extends further.
## What Defenders Should Do Right Now
The public PoC changes the urgency calculation. Scanning activity targeting /ajax/render/pagenav will increase within days — probably hours — of this publication.
ajax/render/ endpoint at the WAF or reverse proxy layer is a partial mitigation but not a substitute for patching./ajax/render/[template] path with suspicious payloads should be filterable. ModSecurity rulesets and commercial WAF vendors will likely add signatures quickly.---
## HackWire Analysis
The story people are underreporting here is Romano's sustained research into vBulletin. Three critical findings in roughly 14 months — including two that were immediately weaponized — suggest that someone is working this codebase systematically, not by accident. Either Romano has found a particularly fertile section of the codebase, or vBulletin's PHP-era inheritance debt is so significant that critical issues are essentially waiting to be found by anyone with the patience to look.
The eval() problem is genuinely embarrassing in 2026. This isn't an obscure edge case or a complicated logic flaw across microservices — it's the most classically dangerous PHP antipattern: unsanitized user input flowing into eval(). The "phpfuck" bypass isn't even sophisticated; it's a well-documented obfuscation technique that competent input sanitization should anticipate. The fact that this survived into production code on a commercial platform suggests either that security review wasn't applied to this function, or that the review failed to model the bypass.
What concerns me more than the vulnerability itself is the 5.x abandonment. vBulletin's project lead confirmed no backport for the legacy branch, but there's no published data on how many active 5.x installs remain on the public internet. My estimate: it's not trivial. Forum migrations are painful, often deferred indefinitely, and the sites most likely to be on 5.x are the least resourced to upgrade. We're going to see compromised community forums surfacing as watering holes or credential farms throughout Q3, and the operators won't immediately understand why.
For hosting providers and managed service companies that run forum hosting: now is a good time to audit your customer base for vBulletin versions and push direct patch notifications. The liability exposure from a preventable breach on software you host is not theoretical.
— HackWire Editorial
---
## Related Coverage