# Public Exploit Drops for vBulletin Pre-Auth RCE — Self-Hosted Forums Now in the Crosshairs
## The Threat
A public exploit for a critical unauthenticated remote code execution flaw in vBulletin hit the internet on July 27, 2026 — nearly four weeks after the vendor quietly shipped fixes. The vulnerability, CVE-2026-61511, lives inside vBulletin's template engine and lets any anonymous visitor execute arbitrary operating-system commands on an unpatched forum server. No account. No administrator interaction. No social engineering required.
The attack path runs through vB5_Template_Runtime::runMaths(), a method in /includes/vb5/template/runtime.php that handles inline math expressions inside templates. The function strips alphabetic characters from user input before passing the remainder to PHP's eval() — a classic restricted-character sandbox that turns out to be not much of a sandbox at all. A public route, ajax/render/pagenav, copies a visitor-supplied pagenav[pagenumber] value directly into a {vb:math} template tag, which feeds straight into runMaths(). That's the chain: public HTTP endpoint → template tag → eval().
What makes this particularly nasty is the technique used to escape the letter filter. SSD Secure Disclosure's advisory describes a method they call "phpfuck" — using only digits, parentheses, arithmetic operators, and bitwise operators like XOR to reconstruct arbitrary PHP strings and callable function names without a single letter. The published proof-of-concept uses this to reassemble PHP's system() function and return command output in the HTTP response body. The exploit as posted contains a one-character typo that prevents it from running unchanged, but the fix is trivial — a letter where a digit should be. Anyone moderately competent will correct it in seconds.
## Severity and Impact
No official CVSS score exists for CVE-2026-61511 at time of writing. The National Vulnerability Database stopped routinely enriching new CVEs with CVSS scores earlier in 2026, so the record remains sparse. Based on the attack characteristics, the practical severity is critical.
| Field | Detail |
|---|---|
| CVE | CVE-2026-61511 |
| CVSS Score | Not yet assigned (NVD enrichment backlog) |
| CWE | CWE-94 (Improper Control of Generation of Code / Code Injection) |
| Attack Vector | Network |
| Attack Complexity | Low |
| Authentication Required | None (pre-authentication) |
| User Interaction | None |
| CISA KEV Listed | No |
| In-the-Wild Exploitation | Not confirmed as of July 27, 2026 |
## Affected Products
No lower version boundary is specified in SSD's advisory. vBulletin Cloud instances have been patched by the vendor. The risk population is self-hosted, internet-facing installations that have not applied patches or upgraded.
## Mitigations
Priority action for all self-hosted vBulletin administrators:
Additional defensive measures:
ajax/render/pagenav with unusual pagenav[pagenumber] values — particularly payloads containing XOR operators, parenthesis-heavy arithmetic expressions, or numeric-only strings that are unusually long## References
---
## HackWire Analysis
The most important detail in this story isn't the vulnerability itself — it's the four-week gap between the vendor's patch and the public exploit drop, and what happened (or didn't happen) inside it.
vBulletin shipped fixes on June 30 and released 6.2.2 on July 1. SSD published the exploit on July 27. That's 26 days during which the vulnerability existed as a patch-differential — security researchers could theoretically reverse-engineer what changed and reconstruct the attack, but the general exploitation population couldn't. Neither SSD nor vBulletin has said anything about whether that window was quiet. There's no statement either way. That silence is worth sitting with.
The researcher credit also raises eyebrows. SSD's advisory names an unnamed independent researcher, but the exploit is signed "EgiX" — Egidio Romano, who is directly responsible for the 2025 vBulletin template-engine RCE chain. Two consecutive years, same researcher, same template engine, same fundamental class of vulnerability. That's not coincidence — it's a signal that vBulletin's template evaluation architecture has a structural problem that one patch cycle hasn't resolved.
The "phpfuck" technique itself deserves attention as a pattern. Restricted-character PHP injection — using only operators and digits to reconstruct arbitrary code — is a known class of bypass that predates vBulletin by years. If your application passes filtered user input to eval() and your filter isn't mathematically sound, the filter is the vulnerability, not just the missing characters. Defenders in any PHP shop should audit every eval() call and every spot where user data reaches dynamic code execution, regardless of how many layers of filtering are in place.
The live exposure right now is concentrated. Cloud customers are already covered. Self-hosted administrators who've been on top of their patch cycle for the past month are covered. What remains is the long tail of neglected self-hosted forums — and vBulletin's user base skews toward communities that have been running the same installation for years without aggressive maintenance. Those are the targets.
— HackWire Editorial
## Related Coverage