On 27 July 2026, working exploit code went public for CVE-2026-61511, a CVSS 9.8 unauthenticated remote code execution flaw in vBulletin's template engine, fixed in vBulletin 6.2.2. The vendor patched it four weeks earlier, at the end of June. That gap is now closed in the worst way: anyone can read the technique, and the barrier to firing it at an unpatched forum is a copy-paste away.
If you run vBulletin and have not updated since June, treat this as urgent. Here is what the bug actually is, why the fix is not just "sanitise the input", and how to tell whether someone got there first.
What it is
| Field | Value |
|---|---|
| CVE | CVE-2026-61511 |
| CVSS v3.1 | 9.8 Critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) |
| CVSS v4.0 | 9.3 Critical |
| Class | CWE-95: eval injection |
| Authentication | None. No account, no admin, no user interaction |
| Fixed in | vBulletin 6.2.2 (released 1 July 2026) |
The flaw was reported by an independent researcher through SSD Secure Disclosure. The public proof-of-concept was published on 27 July by EgiX (Egidio Romano), the same researcher behind earlier vBulletin template-engine work.
Are you affected?
This is where the reporting has been inconsistent, so read carefully.
| Source | Versions listed as affected |
|---|---|
| NVD entry for CVE-2026-61511 | vBulletin 5.0.0 – 5.7.5 and 6.0.0 – 6.2.1 |
| Vendor patch announcement | Security patches issued for 6.2.1, 6.2.0 and 6.1.6; fixed release 6.2.2 |
The NVD record includes the 5.x branch, while the vendor's named patches cover 6.x. Several news write-ups only mentioned the 6.x range. If you are on vBulletin 5.x, do not read the vendor's 6.x patch list as evidence you are safe. Assume you are affected and contact vBulletin about an upgrade path.
vBulletin has stated that Cloud-hosted sites were already patched by the vendor. Self-hosted installations are the exposure.
How the bug works
vBulletin templates support a {vb:math} tag for arithmetic. That tag is handled by vB5_Template_Runtime::runMaths() in /includes/vb5/template/runtime.php.
The method does what a lot of vulnerable code does: it tries to make an expression safe by filtering characters, then hands the survivors to PHP's eval().
The filter strips characters outside an allowed set. It blocks letters, which, on the face of it, sounds like it kills any attempt to call a function, because you cannot write system without letters. What it permits is:
- digits
- parentheses
- arithmetic and binary operators
- string concatenation
That combination is enough. PHP will happily perform bitwise operations on strings, so an attacker can XOR numeric and operator-only values together to reconstruct arbitrary letters at runtime: the technique often demonstrated as "letterless PHP" or phpfuck. The filter never sees the word system; PHP assembles it after the check has passed, and then eval() runs it.
This is the important lesson, and it generalises well beyond vBulletin:
A denylist that blocks the characters of a dangerous word does not stop the value of that word being produced by the language itself.
Why it is reachable without a login
A template bug is only a critical bug if an anonymous visitor can reach it. Here, they can.
vBulletin exposes a public route at ajax/render/pagenav. The stock pagenav template takes the visitor-supplied pagenav[pagenumber] value and drops it into a {vb:math} tag, which is exactly the path into runMaths().
So the chain is short and entirely pre-authentication:
POST /ajax/render/pagenav
│
▼
pagenav[pagenumber] ── visitor-controlled
│
▼
{vb:math} tag in the stock template
│
▼
vB5_Template_Runtime::runMaths()
│
├─ character filter (blocks letters, allows digits/operators/parens)
│
▼
eval() ── payload reassembled via XOR → code execution as the web server user
Code runs with the privileges of the web server process. On a typical forum host that means read access to config.php, and therefore the database credentials, and therefore every user record on the forum.
One detail worth knowing: the published PoC contains a single-character typo (a letter where a digit belongs), so it does not run unmodified. Do not mistake that for a meaningful barrier. It is a one-character fix for anyone who understands the payload.
This is the third time in this component
CVE-2026-61511 is not an isolated slip. The same template engine produced a pre-auth RCE chain in May 2025:
- CVE-2025-48827 (CVSS 10.0): unauthenticated invocation of protected API controller methods, caused by PHP 8.1 changing the behaviour of
ReflectionMethod::invoke() - CVE-2025-48828 (CVSS 9.0): PHP code execution through crafted template conditionals
Those were exploited in the wild within days of the technical details appearing, with attackers hitting /ajax/api/ad/replaceAdTemplate to plant backdoors (on installations whose vendor patch had been available for months).
The pattern matters more than any single CVE: a template engine that compiles user-influenced input into evaluated PHP is a standing RCE surface. Each fix so far has closed one route into eval(), not removed eval() from the design.
Is it being exploited?
As of 27 July 2026:
- No confirmed in-the-wild exploitation has been reported
- CVE-2026-61511 is not listed in the CISA Known Exploited Vulnerabilities catalog
Two cautions against relaxing. First, neither the SSD advisory nor the vendor notices address whether the flaw was exploited during the four weeks between the patch and public disclosure: absence of reporting is not absence of exploitation. Second, the 2025 precedent is that vBulletin bugs get weaponised quickly once the technique is public, and that technique is now public.
What to do today
- Update to vBulletin 6.2.2, or apply the vendor security patch if you are running 6.2.1, 6.2.0 or 6.1.6. On 5.x, contact vBulletin about an upgrade path and treat the install as vulnerable until you have one.
- Virtual-patch at the edge if you cannot update immediately. Block or heavily scrutinise
POSTrequests toajax/render/pagenavwherepagenav[pagenumber]is anything other than a plain integer. A WAF rule rejecting non-numeric input on that parameter closes the specific route. - Hunt for prior exploitation before you assume you are clean. See below.
- Rotate credentials after patching if you find anything: database password in
config.php, any API keys on the host, and administrator passwords.
How to detect exploitation attempts
Search web and application logs for requests to the vulnerable route carrying non-numeric page numbers:
# Requests to the vulnerable render route
grep -E "ajax/render/pagenav" access.log
# The tell: pagenumber that is not a plain integer.
# XOR payloads are dense in ^ operators, parentheses and quotes
grep -E "pagenav(\[|%5B)pagenumber(\]|%5D)=[^&]*[\^\(\)\"']" access.log
Because the payload is delivered by POST, a server logging only query strings will not show the body. If you do not capture POST bodies, pivot to outcome-based hunting instead:
- New or modified PHP files under the web root, especially in
core/,includes/and upload directories: sort by mtime and compare against your last deploy - Unexpected outbound connections from the web server (payloads commonly fetch a second stage)
- New administrator accounts, or existing admin accounts with changed email addresses
config.phpaccess in file-integrity logs
If you find evidence that a crafted pagenumber landed before you patched, treat the host as compromised: rebuild from a known-good backup rather than cleaning in place, then rotate every credential the web server could read.
Frequently Asked Questions
Does blocking letters not make the input safe?
No, and this is the whole bug. Blocking letters prevents an attacker from typing a function name, but PHP can produce letters from operations on non-letter values, XOR on strings being the classic route. The filter validated the characters, not the resulting value, and eval() received the reassembled code after the check had already passed. Filtering is not a substitute for never evaluating user-influenced input.
We are on vBulletin Cloud. Are we affected?
vBulletin has said Cloud sites were already patched by the vendor. The exposure is self-hosted installations, where updating is your responsibility. It is still worth confirming your version rather than assuming.
The exploit is public but there is no reported exploitation. Can we patch next cycle?
We would not advise it. "No confirmed exploitation" as of the disclosure date is a snapshot, not a forecast, and nobody has published telemetry covering the four-week window between the patch and the exploit release. The 2025 vBulletin flaws saw attacks within days of the technique becoming public. Treat a public pre-auth RCE PoC against internet-facing software as a same-week job.
The published PoC does not work. Does that buy us time?
No. The public exploit has a one-character typo (a letter where a digit belongs) that stops it running as published. Correcting it is trivial for anyone who understands the payload construction, and the underlying technique is fully described. Do not build a patching schedule around a typo.
We run vBulletin 5.x and the vendor patch list only mentions 6.x. Are we safe?
Assume you are not. NVD lists 5.0.0 through 5.7.5 as affected. The vendor's named patches cover the 6.x line, which leaves 5.x users in an unclear position. That is a reason to contact vBulletin directly and plan an upgrade, not a reason to conclude the branch is unaffected.
Forum software is a recurring soft spot: internet-facing, rarely in the patch cycle that covers the rest of the estate, and holding every member's email and password hash. A pre-auth RCE in a template engine is exactly the class of flaw we look for in a penetration test, design out of the platforms we build in secure web development, and watch for in managed detection. If you run vBulletin and are not certain whether you were exposed before you patched, talk to us. We can help you check.
