The Slow Death of vBulletin, and Why It Isn't Over

I built addons for vBulletin and XenForo for years, back when a standalone forum was still where a community lived instead of a Discord server nobody can search six months later. I've watched this specific piece of software for a long time, closely enough to remember exactly which forums I administered went dark for a weekend in July 2010 while their admins scrambled to patch something that should never have shipped. I assumed, like most people who lived through that decade, that vBulletin's story ended sometime around 2012, quietly, the way most abandoned software does.

It didn't end. As of the week I'm writing this, vBulletin has a public proof-of-concept exploit circulating for a critical, unauthenticated vulnerability, following a critical remote code execution chain disclosed last year that attackers started exploiting within days. This is Forum Archaeology, a new recurring series where I dig into the platforms and eras I lived through firsthand, with the technical detail intact instead of flattened into nostalgia. First entry: how a piece of software with a brilliant plugin architecture managed to poison its own foundation so thoroughly that the poison is still working, sixteen years later.

The Architecture That Built an Empire

vBulletin launched in 2000, built by James Limm and John Percival, and by the time version 3 arrived in 2004 it had become the default choice for anyone running a serious community forum. If you administered a forum in the mid-2000s, you ran vBulletin, or you explained to your community why you didn't.

The reason it won went beyond polish. It was the plugin system, and understanding exactly how that system worked explains both why developers like me built careers around it and why the software eventually became impossible to secure cleanly. vBulletin's Product and Plugin system let you define hook points throughout the application's execution, places in the codebase the core software would pause at and check: is there any custom code registered here. Plugins were literal PHP code, stored as text in the database, and at each hook point the software would pull that stored code and execute it, effectively running database-stored PHP through the application's request lifecycle without ever touching a single core file.

That's an elegant answer to a real problem. Forum admins could install a hundred addons without patching core, upgrades didn't wipe out custom functionality, and a plugin developer, someone doing exactly what I did for a living, could ship a Product as a portable XML file that installed cleanly on any vBulletin site. The templating system worked on a similar principle: templates lived in the database too, with their own custom conditional syntax that got compiled into executable PHP at runtime.

Sit with that architecture for a second, because it's the same design decision that shows up in a vulnerability disclosed in 2025. Any system that treats stored data as executable code has drawn itself a very specific kind of target: if an attacker can get malicious content into that stored data, however indirectly, they've found a path to code execution that has nothing to do with a traditional buffer overflow or injection flaw. It's a structural property of the system, not a specific bug in it, and structural properties don't get fixed by a patch. They get fixed by a rewrite, or they get inherited by every version that follows, forever.

What the Hook System Looked Like From the Inside

Before the acquisition and the lawsuit and the exodus, I want to slow down on the architecture itself, because I've described it from the outside so far and it deserves a real walkthrough. This is reconstructed from memory of how the Product and Plugin system worked, not copied from vBulletin's source, since that's proprietary code I don't have rights to reproduce, but the shape of it is accurate to how thousands of us built against it for a decade.

A vBulletin hook point, conceptually, looked something like this at the moment execution reached it:

// Simplified reconstruction of the general hook execution pattern,
// not vBulletin's actual source. This is the general shape every
// plugin developer built against.
 
function vB_executeHook(string $hookName, array $context = []): void
{
    $registeredPlugins = vB_Api::getPluginsForHook($hookName);
 
    foreach ($registeredPlugins as $plugin) {
        // Plugin code was stored as a raw PHP snippet in the database,
        // fetched here, and executed directly in the current scope.
        extract($context);
        eval($plugin['phpcode']);
    }
}
 
// Somewhere deep in core/class_core.php equivalent:
vB_executeHook('postbit_display_start', ['post' => $post, 'user' => $user]);

Look at what's happening in that loop. $plugin['phpcode'] is a column pulled straight out of a database table, and it gets handed directly to eval(), PHP's own "treat this string as executable code" function, in the same scope as the variables the core software had already extracted into place for it. That's the entire plugin system: the core application handing a stored string the keys to its own execution context and trusting that whatever's in that column is exactly what it's supposed to be, with no sandbox and no restricted API surface standing between the two.

I want to be precise about why this was a reasonable decision in 2000, rather than calling it a mistake with the benefit of hindsight. Forum admins needed real customization power, more than a plugin API with a fixed set of pre-approved hooks could offer, and giving plugin authors direct PHP access inside the request lifecycle was, at the time, the only practical way to deliver that. I built entire addons this way. Custom post-processing logic, integration with external membership systems, moderation tooling that didn't exist in core, all of it lived as PHP snippets sitting in a database table, executed on every relevant page load. It worked, and it worked well, for exactly as long as nothing malicious ever made it into that table.

That's the whole risk surface in one sentence: nothing malicious ever making it into that table. Every plugin was trusted PHP code by definition, because the mechanism made no distinction between "PHP a forum admin installed on purpose" and "PHP that arrived some other way." An admin panel compromise, a supply-chain problem in a third-party Product someone installed from an unofficial source, or, later, exactly the kind of template-injection bypass I'll walk through below, all led to the identical outcome: arbitrary PHP executing with the same trust level as code the admin explicitly approved, because the system had no separate, lesser trust tier for anything.

A Migration I Lived Through Firsthand

I was doing systems administration work at a hosting company through this exact stretch, 2010 through 2014, which means I wasn't reading about the vBulletin exodus in a retrospective years later. I was fielding support tickets from forum owners living through it in real time, and I did more than one vBulletin-to-XenForo migration myself for clients who'd had enough.

The technical reality of those migrations never matched the marketing promise on either side. XenForo shipped an official vBulletin importer, and it handled the obvious stuff, users, threads, posts, private messages, reasonably well. What it couldn't touch was the actual value most of these forums had built over five or six years: the custom Products. Every plugin I'd built or maintained for a client, every piece of stored PHP living in that hook system, had no equivalent to migrate to, because XenForo's addon architecture was deliberately, correctly, nothing like it. You didn't port a vBulletin plugin to XenForo. You rewrote it from scratch against a real, documented, sandboxed extension API, and for a forum that had accumulated a decade of small custom tooling, that rewrite was often bigger than the migration itself.

I remember one client specifically, a mid-sized community forum I won't identify further than that, who'd paid for four separate custom Products over the years: a custom reputation system, an integration with an external e-commerce platform for handling paid memberships, a moderation queue with logic specific to their community's rules, and a birthday/anniversary notification system nobody outside their community would ever have a reason to build. Migrating their user data took an afternoon. Rebuilding those four Products against XenForo's addon system took most of six weeks, because I wasn't porting code. I was re-implementing behavior that had been described nowhere except inside PHP snippets sitting in a vBulletin database table, snippets that were, by design, undocumented outside whatever comments I'd bothered to leave myself years earlier.

That's the part of this story that doesn't show up in the corporate drama. The lawsuit and the exodus get the headlines. The actual cost landed on admins and developers like me, rebuilding years of accumulated customization against an architecture that was better specifically because it refused to repeat the mistake the old one had baked in from day one.

2007: The Acquisition That Started the Clock

Internet Brands acquired Jelsoft, vBulletin's parent company, in 2007. Nothing broke immediately. What changed was the incentive structure underneath a piece of software that a huge portion of the internet's community infrastructure quietly depended on, and incentive changes at the ownership level take a year or two to show up in the product, then show up all at once.

By 2009, the developers who'd built vBulletin's architecture from the ground up, the people who understood exactly why the hook system worked the way it did and what would break if you touched it carelessly, had left the company. That's not a detail. That's the entire second half of this story starting to load.

2010: The Year Everything Happened at Once

vBulletin 4 went up for presale in November 2009 and shipped in January 2010, and the community's verdict was immediate and brutal. It introduced a new StyleVars system for pulling CSS variables directly from the template layer, a genuine architectural improvement on paper, and shipped it in a state that broke compatibility with a huge share of the vB3 plugin and style ecosystem the community had spent five years building. Forum owners who'd paid for a presale discount got software that, in the words of people running production sites on it at the time, wasn't fit to run in production. It took Internet Brands more than half a year to reach something resembling stability. If you were a plugin developer, and I was, that meant rewriting your entire catalog against a moving target while the core software itself was still shipping breaking changes underneath you.

Then, in July 2010, someone at a mirror of this exact codebase left a debug artifact in faq.php during development of version 3.8.6, a stray line that dumped the software's own MySQL connection credentials to anyone who requested the right page. The BBC covered it. Security researchers published working exploits within days, and Google dorks that let anyone search for exposed installations circulated right alongside them. The fix landed July 21, 2010, but the damage to trust in the platform's engineering discipline had already landed weeks earlier, right on top of a community still furious about the vB4 launch.

And then, in the span of about six weeks that autumn, the entire drama came to a head. On September 21, 2010, Kier Darby and Mike Sullivan, vBulletin's former lead developers, along with former Jelsoft business manager Ashley Busby, publicly announced XenForo, a forum platform built from scratch on the Zend Framework, explicitly positioned as a modern, extensible alternative built by the people who understood exactly what vBulletin had gotten structurally wrong. On October 4, 2010, one day before XenForo's scheduled public beta launch, Internet Brands announced it was suing XenForo and its three founders in the UK, alleging copyright infringement, breach of contract, and misappropriation of trade secrets. A second suit followed in California that November. XenForo launched its beta on schedule anyway, 5.29 PM the night before the lawsuit was announced according to the timestamped announcement that touched off the whole fight, and the forums of both platforms exploded with community reaction within minutes.

The lawsuits dragged on until February 2013, when they were settled confidentially and Internet Brands withdrew both suits. By then it didn't matter who technically won. XenForo had spent two and a half years building a reputation as the platform run by people who cared about the architecture, while vBulletin spent the same two and a half years shipping vBulletin 5 in 2012 to a reception nearly as rough as vB4's had been. The exodus that followed wasn't dramatic in any single moment. It was a decade of forum owners quietly deciding, one migration at a time, that they'd rather run something built by people who understood why the old hook system had been a liability as much as a feature.

Why the Rewrite Mattered

It's tempting to read all of that as pure business drama, a licensing dispute and a lawsuit and not much else. The technical story underneath it is more interesting and more relevant to anyone building software today than the courtroom part.

XenForo wasn't only a competitor with better community sentiment. It was a structural rejection of vBulletin's core architectural bet. Built on Zend Framework, XenForo used a proper MVC structure with a real template compilation and caching layer, addons as first-class, sandboxed extensions rather than database-stored PHP snippets executed at runtime hook points, and a codebase designed from day one by people who'd spent years watching exactly how the hook-and-eval model could go wrong at scale. If you've read how a proper PHP MVC structure separates concerns instead of tangling them together, you already understand the gap between what XenForo was reaching for and what vBulletin had been running on for a decade at that point.

That gap is exactly why the story doesn't end in 2013 with a settled lawsuit and a platform that lost the argument. It ends, or rather doesn't end, in the security disclosures still coming out of vBulletin's codebase today, more than two decades after the architecture that produces them was first written.

2025 and 2026: The Debt Comes Due, Again

In May 2025, security researcher Egidio Romano disclosed a critical vulnerability in vBulletin's template engine, tracked as CVE-2025-48828, that let attackers execute arbitrary PHP through the template conditional system by crafting an alternative PHP function invocation syntax the engine's security checks failed to catch. Paired with CVE-2025-48827, an API method invocation flaw affecting versions 5.0.0 through 5.7.5 and 6.0.0 through 6.0.3 running on PHP 8.1 or later, the two vulnerabilities could be chained toward remote code execution, and CVE-2025-48827 carried a maximum severity score of 10 out of 10. Researcher Ryan Dewhurst observed exploitation attempts in his own honeypot within days of the vulnerabilities becoming public, originating from Poland, against a bug that had reportedly been patched quietly months before public disclosure while many forum operators never applied the fix.

Read that architecture description again: attackers bypassing security checks by exploiting alternative syntax the template engine's conditional processor was never hardened against. That's the same category of structural weakness the original hook-and-eval design carried from day one, running in production, sixteen years after the developers who understood that risk best had already left to go build something without it.

It's worth making that bypass concrete instead of leaving it abstract, because the general shape of this class of bug is one every PHP developer building a templating or macro system should recognize on sight. A template engine that needs to support conditional logic has to parse function-call-looking syntax out of a template string and decide whether that particular function call is safe to execute. A naive version of that safety check does something like this:

// Illustrative reconstruction of the general vulnerability class,
// not the literal vBulletin patch. The pattern is what matters.
 
function isTemplateFunctionSafe(string $functionCall): bool
{
    // Checks for the standard call shape: functionName(args)
    if (preg_match('/^([a-zA-Z_][a-zA-Z0-9_]*)\s*\(/', $functionCall, $matches)) {
        $functionName = $matches[1];
        return in_array($functionName, ALLOWED_TEMPLATE_FUNCTIONS, true);
    }
 
    return false; // Doesn't look like a function call, reject it
}

That check works fine against the exact syntax it was written to expect. The problem is everything PHP's parser accepts that this regular expression never anticipated. PHP has more than one way to write a callable invocation, variable variables, callable arrays, string-based dynamic dispatch through functions like call_user_func(), and a security check written against one specific textual pattern doesn't automatically cover every syntactic path the underlying language permits. An attacker who understands PHP's full grammar better than the person who wrote that regular expression can construct a call that means "execute this function" to PHP's actual parser while looking like something entirely different, or nothing at all, to a check built around one expected shape. That's precisely the kind of gap CVE-2025-48828 exploited: an alternate invocation syntax the template engine's safety net had never been built to recognize as the same threat.

This is, again, the identical lesson from the PHP object injection section earlier in this piece, and from the EchoLeak breakdown over in Ghost Check's first entry. A security check built to catch one specific pattern of malicious input is only as strong as how completely that pattern covers every equivalent way to express the same underlying operation. Microsoft's XPIA classifier didn't fail because Microsoft's engineers were careless. It failed because a classifier trained to recognize known injection patterns has the same structural blind spot as a regular expression built to recognize known function-call syntax: both are pattern-matching against a moving target that the underlying system's actual grammar makes infinitely reformattable.

The pattern repeated almost exactly one year later. In late June 2026, vBulletin issued security patches for versions 6.2.1, 6.2.0, and 6.1.6, followed by the 6.2.2 release on July 1 that fixed a pre-authentication code execution flaw tracked as CVE-2026-61511. A public exploit went live nearly four weeks after the patch, banner calling it a zero-day despite the fix already being available, and as of the most recent reporting no confirmed in-the-wild exploitation had surfaced, though the exploit's proof-of-concept code was public and only one small transcription error away from working as published. This is, per the researchers tracking it, the same corner of vBulletin's codebase that produced the 2025 chain: a quiet patch goes out first, a working exploit surfaces weeks later, and a meaningful share of self-hosted, internet-facing forums are still running the vulnerable build when it does.

That's not a coincidence of timing. That's a codebase whose oldest architectural decisions keep generating the same shape of vulnerability, on a roughly annual cadence, because the fundamental approach, executing structured content through a custom parsing and conditional layer that has to correctly distinguish legitimate syntax from malicious syntax every single time, was a liability baked into the design before Internet Brands ever bought the company, and nobody has rewritten that layer from the ground up the way XenForo's founders rewrote everything else.

What This Teaches You, Beyond the Nostalgia

If you're running any self-hosted platform today, and a meaningful share of you reading this run something with supply chain and self-hosting exposure of your own, the vBulletin story isn't a museum piece. It's a live warning about three separate failure modes stacking on top of each other, and every one of them is still available to repeat.

The first is architectural debt that outlives the people who understood it. vBulletin's hook system was a reasonable design choice in 2000, made by developers who understood its risks and could compensate for them in review. Once those specific people left, the risk didn't leave with them. It stayed baked into the architecture, waiting for whoever inherited the codebase to rediscover it the hard way, one CVE at a time, for over fifteen years and counting.

The second is what happens when a community's platform decision gets made by a company that acquired the software as an asset rather than built it as a craft. Internet Brands didn't cause the July 2010 credential leak or the vB4 launch disaster directly. What corporate ownership changed was the incentive to invest in the deep, unglamorous architectural work that prevents those failures, the work that doesn't show up in a quarterly report until the year it very publicly doesn't hold.

The third, and the one worth sitting with if you're choosing where your own community lives right now, is that the platforms replacing standalone forums today, walled-garden Discord servers, Slack workspaces with institutional knowledge nobody can search past ninety days, are making a different version of the same mistake vBulletin's community eventually walked away from: trusting a platform you don't control with knowledge you can't easily leave with. The decline of Stack Overflow is the same story again, a decade later, on a different platform, for reasons that rhyme with this one more than they differ from it.

We recommend reading The Decline of Stack Overflow next if this pattern feels familiar. It's the same slow institutional death vBulletin went through, playing out on a platform a lot of you are still actively using today, and the parallels are closer than either community wants to admit.

Why Stack Overflow Is Dying and What Replaced It

How Stack Overflow went from the most useful site for developers to something people actively avoid — and what AI replacing it actually means.

CoderOasisTraven

I don't administer a vBulletin forum anymore, and I haven't built a Product for one in a long time. What I still have is the muscle memory of exactly which hook points needed the most careful review, and a healthy respect for how long a bad architectural decision keeps generating consequences after everyone who made it has moved on to something else. Sixteen years is a long time for a piece of software to keep proving that point. It's still proving it right now, this month, to anyone running an internet-facing installation that hasn't applied the last patch.