A newly released public exploit for a critical vBulletin remote code execution (RCE) vulnerability is raising concerns for administrators of self-hosted forums. The exploit, published on July 27, demonstrates how attackers can execute arbitrary code on vulnerable servers without authentication, user interaction, or administrative access.
Although patches have been available for nearly a month, forums that have not yet updated remain exposed to potential compromise.
What Is CVE-2026-61511?
The vulnerability, tracked as CVE-2026-61511, affects vBulletin’s template engine and allows unauthenticated attackers to reach PHP’s eval() function, enabling remote code execution.
According to SSD Secure Disclosure, the following versions are affected:
- vBulletin 6.2.1 and earlier
- vBulletin 6.1.6 and earlier
The advisory does not specify the earliest vulnerable release.
vBulletin addressed the issue with security patches released in late June for versions 6.2.1, 6.2.0, and 6.1.6, followed by the release of vBulletin 6.2.2 on July 1—almost four weeks before the exploit became public.
Cloud Customers Already Protected
The vulnerability only poses a risk to self-hosted vBulletin installations that have not been updated.
According to the vendor:
- vBulletin Cloud instances have already been patched.
- Self-hosted administrators should either apply the appropriate security patch for their version or upgrade directly to vBulletin 6.2.2.
No Confirmed Active Exploitation Yet
As of July 27, 2026, there are no confirmed reports of active exploitation of CVE-2026-61511.
Additionally:
- The vulnerability is not listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog.
- SSD Secure Disclosure stated that it has not observed attacks in the wild.
However, security researchers note that it’s impossible to determine whether attackers quietly exploited the flaw during the roughly four-week period between the vendor’s patch release and the public disclosure.
Public Proof-of-Concept Contains a Minor Error
SSD published an interactive proof-of-concept (PoC) alongside its advisory. Interestingly, the released exploit includes a single-character typo—a letter appears where a number should be.
While this mistake prevents the exploit from working exactly as published, researchers confirmed that correcting the typo immediately restores functionality. The error does not reduce the severity of the underlying vulnerability.
How the Vulnerability Works
The flaw exists inside the file:
/includes/vb5/template/runtime.php
Specifically, the vulnerable function is:
vB5_Template_Runtime::runMaths()
This method processes inline mathematical expressions used within templates.
Although the function attempts to sanitize input by filtering out disallowed characters, it eventually passes the remaining expression directly to PHP’s eval() function.
Researchers discovered that the filtering rules still allow:
- Numbers
- Parentheses
- Arithmetic operators
- String concatenation
- Binary operators such as XOR
Using these permitted characters, attackers can reconstruct PHP strings and function names without using alphabetic characters—a technique referred to in the advisory as “phpfuck.”
No Login Required
One of the most concerning aspects of the vulnerability is that attackers do not need access to the administration panel.
The exploit targets the publicly accessible endpoint:
ajax/render/pagenav
The default pagenav template inserts user-controlled input from the pagenav[pagenumber] parameter into a {vb:math} tag, which is then processed by the vulnerable runMaths() function.
This chain allows an unauthenticated attacker to execute arbitrary operating system commands and receive the output directly in the server’s HTTP response.
Researchers Verified the Vulnerability
Security researchers independently reproduced the filtering and evaluation behavior described in SSD’s advisory.
Testing showed that:
- The published exploit fails because of the typo.
- After correcting the typo, harmless test payloads execute successfully.
- The issue lies in the expression evaluation logic rather than the proof-of-concept itself.
The researchers emphasized that their testing validated the vulnerability without targeting any live vBulletin servers.
Is This Really a Zero-Day?
Although the exploit labels the vulnerability as a zero-day, the timeline tells a different story.
The vendor had already:
- Released security patches in late June.
- Published the fixed vBulletin 6.2.2 release on July 1.
The exploit became public nearly four weeks later.
In practice, the exploit code is new, but the underlying vulnerability had already been patched. As a result, the primary risk now falls on organizations still running outdated, internet-facing, self-hosted vBulletin installations.
Detection Recommendations
Administrators should monitor web server logs for suspicious POST requests containing:
routestring=ajax/render/pagenav- Unusually long
pagenav[pagenumber]values - Inputs containing excessive arithmetic or binary operators
These indicators are derived from the public proof-of-concept and may help identify attempted exploitation.
A Familiar Pattern for vBulletin
This is not the first time vBulletin’s template engine has been associated with pre-authentication remote code execution vulnerabilities.
In May 2025, vulnerabilities CVE-2025-48827 and CVE-2025-48828 exposed a different attack path through the same template engine. Those flaws began seeing exploitation attempts shortly after public disclosure, despite patches having been available months earlier.
The latest disclosure follows a similar pattern:
- Vendor releases a quiet security fix.
- Public exploit appears weeks later.
- Many self-hosted forums remain unpatched and vulnerable.
Final Thoughts
While there are currently no confirmed reports of active attacks targeting CVE-2026-61511, the availability of a working public exploit significantly increases the likelihood of exploitation attempts.
Organizations running self-hosted vBulletin forums should treat this as a high-priority update. Applying the latest patches—or upgrading to vBulletin 6.2.2—remains the most effective defense against this critical remote code execution vulnerability.
