SSD Secure Disclosure published a working exploit for CVE-2026-61511 on July 27, 2026, turning a disclosed but unpatched vulnerability in vBulletin forum software into an immediate threat for every site still running version 6.2.1 or earlier. The exploit was developed and signed by researcher Egidio Romano, known as EgiX, and reaches an unauthenticated public route that requires no credentials, admin access, or user interaction to deliver code execution on the server.
The eval() Injection at the Heart of CVE-2026-61511 in vBulletin
CVE-2026-61511 originates in the runMaths() method within vBulletin’s template engine. The method is designed to evaluate mathematical expressions used in templates by stripping characters outside a permitted set and then passing the remaining input directly to PHP’s eval() function — a design that, when the character-stripping step fails to prevent code injection, becomes a direct path for arbitrary PHP execution.
The flaw is that the character filtering does not prevent construction of executable PHP from permissible characters. An attacker who crafts input that passes the filter while still constituting valid PHP code causes eval() to execute that code on the server with the permissions of the vBulletin web process.
The Vulnerable ajax/render/pagenav Route and EgiX’s Weaponized Exploit
The runMaths() vulnerability is reachable via the ajax/render/pagenav route — an endpoint exposed to the public internet that requires no login, no prior account, and no user-side interaction. An attacker sending a single crafted HTTP request to any vBulletin server running an affected version can trigger code execution without touching any authenticated code path.
Researcher Egidio Romano signed and released the exploit through SSD Secure Disclosure on July 27. A CVSS score has not yet been assigned to CVE-2026-61511 because NVD reduced its CVE enrichment capacity earlier in 2026. The absence of a formal CVSS score does not affect the severity assessment: unauthenticated RCE via a public route on a widely deployed web application is by definition in the highest-priority remediation category regardless of score.
No confirmed in-the-wild exploitation has been reported as of the July 27 public release, and CVE-2026-61511 does not appear in CISA’s Known Exploited Vulnerabilities catalog at this time. The publication of a fully weaponized, signed exploit eliminates the protection that organizations previously had from unpatched systems: any attacker with the exploit code can now attempt it against any reachable vBulletin 6.x instance that has not yet applied the available patch.
Why vBulletin 6.2.2 Is the Only Safe Version After SSD’s July 27 Release
vBulletin released security patches for versions 6.2.1, 6.2.0, and 6.1.6 in late June 2026. The fixed release, version 6.2.2, became available on July 1, 2026. Any installation still running 6.2.1, 6.1.6, or any earlier 6.x release remains vulnerable to the exploit EgiX published on July 27. Version 6.2.2 or later is required to remove the CVE-2026-61511 attack path.
The gap between the original patch availability and the public exploit publication represents the period during which organizations running unpatched installations were exposed to a disclosed but not yet weaponized vulnerability. With the exploit now public, organizations that did not update during that window are now in a more urgent position: the attack is no longer theoretical and no longer requires specialized knowledge to attempt.
Scope of Exposure: Forum Operators Running vBulletin 6.x Across Multiple Sectors
vBulletin powers community forums across media, gaming, automotive, enterprise support, educational, and professional communities. Server-side RCE exploitable without authentication means an attacker can execute code on the web server hosting the forum, with potential consequences including full database access, theft of user credentials, session hijacking, webshell installation for persistent access, or staging the server as a platform for delivering malicious content to forum visitors.
Forum administrators running vBulletin 6.x should upgrade to version 6.2.2 immediately and confirm the update applies to all instances. Given the public availability of a working exploit, the interval between exploit publication and mass automated scanning of vBulletin installations is measured in hours, not days. Organizations that have delayed this update since the June–July patch release need to prioritize the upgrade as an immediate security action rather than a routine maintenance item.
