vBulletin Forum Software Hit by Critical Flaw CVE-2026-61511: Unauthenticated Server Takeover
vBulletin, the forum software used by community sites worldwide, has a flaw (CVE-2026-61511, severity 9.8) that lets anyone take over the server without logging in. A working exploit was published on July 27, 2026, though no in-the-wild attacks have been confirmed. Versions up to 5.7.5 and 6.2.1 are affected; the fix is to update to 6.2.2 immediately.
Table of contents
vBulletin, the forum software used by community sites worldwide, has a flaw (CVE-2026-61511, severity 9.8) that lets anyone take over the server without logging in. A working exploit was published on July 27, 2026, though no in-the-wild attacks have been confirmed. Versions up to 5.7.5 and 6.2.1 are affected; the fix is to update to 6.2.2 immediately.
vBulletin, the forum software used by community sites around the world, has a critically dangerous vulnerability (software weakness) that lets anyone take over the server without logging in. It is CVE-2026-61511, rated 9.8 out of 10 in severity (the top "Critical" level). On July 27, 2026, a working exploit (ready-to-run attack code) was published, raising the risk—though as of that date no in-the-wild attacks have been confirmed (see the update and correction at the top).
Affected are the 5.x line (up to 5.7.5) and the 6.x line (up to 6.2.1). The vendor has released the fixed version 6.2.2, and the remedy is to update to it. Forums are usually placed where anyone can reach them, so the door for attack is always open. If your site is older than this version right now, we strongly recommend updating immediately.
Update & correction, July 27, 2026 — A working exploit is public, but no in-the-wild attacks have been confirmed
On July 27, 2026, a working public exploit (ready-to-run attack code) for CVE-2026-61511 was released. The code is an "eval injection" that feeds a crafted value into the math routine runMaths() in runtime.php, using a technique called "phpfuck" that builds PHP code without alphanumeric characters to slip past the input check (sanitization). With the method now public, the bar to attack has dropped sharply. The affected versions are 6.2.1 and earlier, and 6.1.6 and earlier. The fixed release 6.2.2 shipped on July 1, 2026, and the same fix is provided to older branches as a backport labeled Patch Level 1. (Sources: The Hacker News, BleepingComputer, Security Online)
Correction: no real-world attacks have been confirmed. Our first report stated that the flaw was "already being used in real-world attacks." That was incorrect. As of July 27, 2026, no in-the-wild exploitation has been confirmed, and it is not listed in the "Known Exploited Vulnerabilities (KEV)" catalog published by the U.S. agency CISA. The current stage is "a working exploit is public, but no in-the-wild attacks are confirmed." We have revised the corresponding wording in the body to match, and we apologize for the error.
What you need to do now: Even without confirmed in-the-wild attacks, the release of a working exploit raises the risk. If you run an affected version, update to 6.2.2, or apply Patch Level 1 on an older branch, right away. We also recommend checking whether you have already been breached, following the steps in the body, before you consider the matter closed.
Overview of the vulnerability
First, the overall picture. The severity figure is CVSS, an international scale that rates a vulnerability's danger out of 10.
| Item | Detail |
|---|---|
| Vulnerability ID | CVE-2026-61511 |
| Affected software | vBulletin (forum software) |
| Affected versions | 5.x–5.7.5 6.x–6.2.1 |
| Fixed version | 6.2.2 |
| What happens | Run arbitrary code without logging in |
| Severity (CVSS) | 9.8 (Critical) |
| Exploitation | Working PoC public (no in-the-wild attacks confirmed) |
"Run arbitrary code (remote code execution)" means an attacker can run a program of their own on your server. Because it works without any login, a vulnerable site can be targeted by anyone as long as it is public. When those two conditions combine, the damage is about as bad as it gets.
What vBulletin is
vBulletin is a commercial forum software for building bulletin boards and community sites. Written in the PHP programming language, it has long been used by large fan sites, gaming communities, and corporate support forums—member-based sites around the world.
Among forum products it is a veteran with many deployments, and per the vBulletin official site it bundles posting, member management, and permission settings. Being feature-rich, its internals are complex, and it is a product that has repeatedly seen the same kind of "template-feature takeover" reported before. This vulnerability belongs to that lineage.
Who is targeted, and what is the goal
Numbers alone rarely make it feel personal, so let us break down who would attack and what they are after.
The ones exploiting this hole are attackers who scour the internet for forum sites one after another. Because no login or account is needed, they do not pick targets; they use automated tooling to mechanically find vulnerable vBulletin sites and launch attacks. No in-the-wild attacks have been confirmed yet, but a working exploit was published on July 27, 2026, setting the stage for mechanical, opportunistic abuse.
Such an attacker sends a crafted string into one of the forum's input endpoints and runs their own program on the server, taking over the entire site. After takeover, that leads to secretly creating an admin account, planting a backdoor file (a web shell), stealing members' personal data, or defacing the site to use it as a springboard for further attacks.
The damage differs by role. For members who visit the site, the email addresses and passwords they registered could be stolen and reused to break into other services. For the operators, losing control of the server itself brings enormous cost in recovery and rebuilding trust. That is why updating to 6.2.2, shown in the next section, is the top priority.
How the vulnerability works
CVE-2026-61511: code is injected through the math-processing endpoint
This vulnerability lurks in the math-evaluation processing inside vBulletin's template feature (the mechanism that assembles how a page looks). Technically, sending a crafted value in the pagenav[pagenumber] field—via an internal endpoint (an AJAX route) reachable without logging in—causes that value to be executed as a program. It is classified as an "eval injection" (CWE-95), a type of flaw where a submitted string runs directly as code.
The nasty part is that the input check meant to block dangerous characters (a regular-expression filter) is too loose, and can be bypassed with a special form of PHP code written without alphanumeric characters. It is a textbook case of a filter that looks safe being evaded with an unexpected style of input, resulting in pre-authentication arbitrary code execution. Per the NVD assessment, it scores 9.8 on CVSS 3.1 and 9.3 on CVSS 4.0—top-tier danger either way.
Check whether your site is affected
Check the vBulletin version you use, in the admin panel or the installed files. The table below tells you whether you are affected.
| Your version | Status | Action |
|---|---|---|
| 5.0–5.7.5 | Affected (dangerous) | Update to 6.2.2 |
| 6.0–6.2.1 | Affected (dangerous) | Update to 6.2.2 |
| 6.2.2 and later | Fixed | No action needed |
What to do now
The fundamental fix is to update vBulletin to 6.2.2. Since a working exploit is already public, it is worth applying quickly—even if that means posting a maintenance notice. Follow the official vBulletin guidance and take a backup before updating.
If you cannot update right away, temporary mitigations include using a defensive layer in front of the forum (a WAF, which detects and blocks malicious traffic) to stop suspicious requests containing pagenav[pagenumber], and isolating the admin panel and unnecessary AJAX endpoints from outside view. But these only buy time; the real fix is the update.
Also, do not forget to check whether you have already been compromised. With a vulnerability that allows arbitrary code execution, you may have been breached before updating. Look for admin accounts you do not recognize, unfamiliar PHP files in the install folder (backdoor web shells), and suspicious traffic in your server's access logs. If anything looks off, do not assume the update alone is enough—consider an investigation by a professional. The pattern of a hijacked site becoming a springboard for attacks on others was the same in the site takeovers via Joomla page builders.
Because a working exploit for this vulnerability is public, it may be added to the "Known Exploited Vulnerabilities (KEV)" catalog published by the U.S. agency CISA if in-the-wild exploitation spreads. Checking the latest CISA KEV status as well makes it easier to judge how urgently to respond.
A technical view: why forum software keeps getting taken over
Feature-rich forum software like vBulletin includes an internal mechanism to "interpret strings as programs and run them," so it can assemble page appearances flexibly. Convenient as that is, the mechanism sits right next to the danger that a string arriving from outside gets executed as-is. This math processing was one such case.
Even with a filter to block dangerous input, unexpected escapes—like writing code without alphanumeric characters—keep turning up. The "list dangerous things and forbid them" approach breaks whenever someone uses a style not on the blocklist. That vBulletin has repeatedly seen the same template-based takeovers reflects this structural difficulty. Fundamentally, the design needs to move toward never treating external input as something to execute.
Summary
vBulletin's CVE-2026-61511 is a severity-9.8 vulnerability that lets anyone take over the server without logging in, and a working exploit was published on July 27, 2026 (no in-the-wild attacks confirmed as of that date). Affected versions are up to 5.7.5 and up to 6.2.1, and the fix is to update to 6.2.2. Because a forum is always open to the outside, a delayed update translates directly into damage.
First, check your site's version, and if affected, update to 6.2.2 immediately. Then, to be safe, go as far as checking whether you have already been breached. If exploitation spreads further or it is added to the KEV catalog, we will update this article.
Sources
Backend Engineer / AWS / Django