SURIQ
The vBulletin flaw disclosed today is not dangerous because of its severity score. It is dangerous because of its calendar. The patch has been available for almost four weeks, the full technical write-up and a working proof-of-concept went public today, and the software it targets is the kind that sits online for years with nobody watching it.
CVE-2026-61511 is an unauthenticated remote code execution vulnerability in the vBulletin forum platform. It scores CVSS 9.8 on the v3.1 scale and 9.3 on v4.0, per the VulnCheck advisory that assigned it. An attacker needs no account, no password, and no interaction from a user. They need a network path to the forum, which for most vBulletin installs is the open internet.
Where the code execution comes from
The bug lives in the template engine. vBulletin lets template authors do arithmetic through a {vb:math} tag, and behind that tag sits a method named runMaths() in the template runtime. To evaluate the expression, runMaths() filters the input with a regular expression that permits only digits, parentheses, and math operators, then hands the filtered string to PHP's eval().
The filter is the whole defense, and it is not enough. Security researcher Egidio Romano, reporting through SSD Secure Disclosure, showed that the character whitelist can be bent: PHP will happily build strings and call functions out of nothing but operators and permitted characters, so arbitrary PHP slips past a filter that was only ever checking for math. The write-up on Karma(In)Security documents the same root cause. A proof-of-concept was published alongside the disclosure, so this is not theoretical.
The part defenders care about most is reachability. The vulnerable path is exposed through vBulletin's unauthenticated ajax/render route, where the pagenav[pagenumber] parameter flows into the template math evaluation. No login gate stands between a stranger and that code. We are not reproducing the payload here; the mechanism above is enough to assess your exposure, and the primary sources carry the detail.
Here is who needs to act, by branch.
| vBulletin branch | Affected by CVE-2026-61511 | What to do |
|---|---|---|
| 6.2.2 and later | No | You are on the fixed release |
| 6.2.1, 6.2.0, 6.1.6 | Yes | Apply the vendor security patch, or move to 6.2.2 |
| 6.0.0 to 6.1.5 | Yes | Upgrade to 6.2.2 |
| 5.0.0 to 5.7.5 (end of life) | Yes | No branch patch shipped; migrate to 6.2.2 |
The 5.x line matters here. It reached end of life, and the vendor's patch cycle covered only the 6.x branch, so an operator still on 5.x has no drop-in fix and must upgrade the major version. That is a heavier lift than a point release, which is exactly why some of those forums will stay vulnerable.
The timing is the real risk
Read the timeline before you decide how urgent this is.
The vendor was notified on June 25, shipped a security patch on June 30, and released 6.2.2 on July 1. The technical details and proof-of-concept went public today, July 27. That roughly four-week gap was a quiet head start, and it only helped the operators who used it. Everyone still on an old build now faces a fully documented, working exploit with a map to the vulnerable parameter.
That gap-then-drop rhythm is where vBulletin has burned defenders before. The 2019 template-render flaw (CVE-2019-16759) was exploited across tens of thousands of forums within days of its public details, according to reporting at the time. The 2025 pair Romano disclosed (CVE-2025-48827 and CVE-2025-48828) drew in-the-wild exploitation shortly after his write-up, per that same coverage. As of this writing there is no public confirmation that CVE-2026-61511 is being exploited yet. History says the window between public PoC and opportunistic mass-scanning of a bug this easy to reach is short, as we saw when a GitLab remote code execution flaw drew a public exploit, so treat an unpatched forum as a matter of when, not if.
The template engine keeps being the soft spot
Step back from this one CVE and a pattern shows up. vBulletin's remote code execution flaws keep coming from the same organ: the template system that turns forum data into rendered pages. The 2019 bug abused template rendering. The 2025 flaws abused how the template runtime could be made to invoke methods it should not. This one abuses a math helper inside that runtime that reaches eval(). Different entry points, one underlying property: a template engine is a small language interpreter, and any place it lets attacker-influenced input become executed logic is a code-execution bug waiting to be found. It is the same shape we saw in template injection in the Formie plugin for Craft CMS, and it is why unauthenticated flaws in forum and CMS software, like the unauthenticated remote code execution in Joomla's JCE editor, draw attackers so quickly.
For anyone running vBulletin, the practical read is to treat the whole unauthenticated render surface as high-value attacker territory, not just the specific parameter named this week. The next one, if the history holds, will come from the same neighborhood.
Patch to 6.2.2, then hunt the render route
The fix is unambiguous, so do the boring thing first. Move to vBulletin 6.2.2, or apply the vendor security patch for 6.1.6, 6.2.0, or 6.2.1. If you are on 5.x, there is no patch for that branch and the upgrade to 6.2.2 is the path.
Because the patch is old and the exploit is new, patching alone is not the finish line. Assume unpatched forums may already have been touched, and hunt for it:
- Watch the unauthenticated
ajax/renderroute for anomalous requests, especially odd or encoded values inpagenavparameters. - Look for PHP execution anomalies from the web user: unexpected new or modified files under the forum webroot, and outbound network connections a forum process has no reason to make. Web shells are the usual first payload after a bug like this.
- Review admin accounts, scheduled tasks, and template edits for changes you did not make.
This is where continuous monitoring earns its place. A managed detection setup watching the web tier can flag the anomalous unauthenticated render request and the post-exploitation behavior that follows it, mapped to the relevant MITRE ATT&CK techniques, which is what tells you whether a slow patch turned into an actual intrusion.
The forums most exposed to this are the ones nobody logs into anymore: the legacy community site from a product launch five years ago, still running, still indexed, still on a 5.x build. If your organization stands up that description, today is the day to find that host and either patch it or retire it. An abandoned forum is still a server on your network, and this bug turns it into a foothold.