A Public Exploit Just Landed for vBulletin. The First Fix for This Class Shipped With No CVE at All.

Working exploit code is now public for a patched pre-authentication code execution flaw in vBulletin. Unpatched forum servers can be made to run code from an unauthenticated request that reaches PHP's eval().

Pre-auth. No credentials, no account, no interaction. Send the request, run the code.

If you run a vBulletin forum, this is a tonight item. Not a maintenance-window item.

Who this actually hits

vBulletin runs message boards. Car clubs. Hobby forums. Regional sports communities. Trade groups. University alumni associations. Fan communities that have been online since the early 2000s and have twenty years of member data in a MySQL database.

Those operators are the population we exist to write for. There is no security team. Often there is no team — there is one volunteer administrator who set the thing up years ago, keeps the hosting bill paid, and moderates on evenings and weekends. They are not reading advisories. They are not running a vulnerability scanner. They do not have an EDR agent, a SIEM, or anybody to call.

And they are sitting on exactly the data that makes extortion work: real names, email addresses, private messages, IP logs, and password hashes for members who reused those passwords everywhere. A forum breach is not a low-value breach. It is a credential-stuffing supply depot and a sextortion mailing list, which is precisely how the ShinyHunters-branded leaks we wrote about this morning end up monetized.

Pre-auth RCE on that population, with public exploit code, is about as asymmetric as this job gets. The attacker needs a scanner and an afternoon. The defender needs to happen to find out.

The lineage, and the part that should make you angry

vBulletin's recent history with this class of bug is worth laying out, because it explains why so many forums stay unpatched.

The best-documented chain is CVE-2025-48827 and CVE-2025-48828 — CVSS 10.0 and 9.0. They affect vBulletin 5.0.0 through 5.7.5 and 6.0.0 through 6.0.3 when running on PHP 8.1 or later. The mechanism was invoking protected API controller methods through crafted URLs, then abusing template conditionals in vBulletin's own template engine to reach code execution. Egidio Romano, who publishes as EgiX, found them and wrote them up in detail on May 23, 2025. Exploitation in the wild was observed within days, on May 26.

Here is the detail that matters more than any of those numbers: the underlying issue was reportedly patched back in April 2024, with no CVE identifier assigned at the time.

Think about what that did to every small operator running that software. The fix existed for roughly a year before anyone gave it a name a scanner could recognize. During that year, an administrator doing everything a reasonable non-expert can do — subscribe to security notices, patch when told something is a security problem — would have received no signal. There was no CVE to alert on, no CVSS to sort by, no advisory to forward to their host. The protection shipped. The information did not.

Then a researcher published, and attackers were on it in three days.

We wrote almost this exact paragraph yesterday about GitLab filing a remote code execution fix under bug fixes, and again today about an n8n sandbox escape with no CVE assigned. Three in a week, three different vendors, one shape: the patch is real, the label is missing, and the defender's entire triage system runs on the label.

What we could not confirm, stated plainly

We could not confirm which specific CVE the exploit released on July 27 targets, or whether it is the 2025 chain above or a distinct newer flaw. We looked; the reporting we can access names the behaviour and the impact but not the identifier, and we are not going to guess an identifier and let it get quoted back at us.

So take the specific numbers above as the documented lineage of this bug class in vBulletin, not as a confirmed match to today's release. The action item does not change either way — if your vBulletin is not current, you are exposed to a public pre-auth exploit right now, and which CVE it maps to is an academic question you can answer after you patch.

We would rather publish a post with a named gap in it than a post with a confident wrong number in it. Ingest time is not detection time, and a plausible CVE is not a verified one.

What to do, in order

Get to the latest vBulletin release today. Not this week. Public pre-auth exploit code against a web-facing PHP application is the highest-urgency category there is, because it automates perfectly and there is no user to trick.

If you cannot patch tonight, get the forum off the open internet tonight. Put it behind Cloudflare with an under-attack posture, restrict access at the host firewall, or take it offline for a day. A forum that is down for 24 hours is an inconvenience. A forum that is breached is twenty years of member data on a leak site, and in most jurisdictions a notification obligation you cannot afford to handle.

Check whether you are already compromised, and assume it before you disprove it. Look for PHP files with recent modification times anywhere in your webroot, especially in upload, cache, and template directories. Look for unfamiliar administrator accounts. Look at your web server access logs for unauthenticated POSTs to admin or API endpoints, and for any request pattern that repeats from one address across many paths. Exploitation of this class was seen in the wild days after the last PoC drop; assume scanning started immediately this time too.

Rotate everything the forum knows. The database credentials in your config file. Any API keys. Your own administrator password, from a machine that is not the server. If code ran, the config file is the first thing it read.

Tell your members to change reused passwords. Even if you cannot prove a breach. Forum password hashes are the raw material of credential stuffing, and your members deserve a heads-up more than you deserve to avoid an awkward announcement post.

Check your PHP version too. The documented 2025 chain depended on PHP 8.1 or later. Knowing your PHP version tells you which historical variants applied to you, which matters for judging how long you may have been exposed.

The argument underneath

Small operators do not fail at security because they are careless. They fail because the security ecosystem is built for organizations with staff. Every mechanism we have for telling people they are in danger — CVE feeds, scanners, advisory mailing lists, severity scores — assumes somebody is employed to receive the message. Forum administrators are not that. They get the message when the exploit is already public and somebody blogs about it in language they can act on.

Which is the job. If you run one of these boards, or you know somebody who does, the entire useful content of this post is one sentence: update vBulletin today, because working attack code is public and it does not need to log in.

We are 95 percent confident forums running this software get hit at scale within the next two weeks, because that is what happened the last time a PoC for this class went public and nothing about the exposed population has improved since. The remaining five percent is the chance the exploit is fiddly enough, or the patched-version share high enough, that mass scanning does not pay off. We would not plan around it.

Credit to Egidio Romano for the original research on the documented chain, and for publishing it in enough detail that defenders could understand what they were patching.

Free IP, domain, hash, and malicious-package blocklists at analytics.dugganusa.com.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.