Forum Archaeology: Nulled vBulletin, XenForo, and the Missing Footer

I could usually tell in about four seconds, and I'm not going to pretend it wasn't funny every single time.

Scroll to the bottom of the page. Look at where the copyright line should be. Nothing there — or it's mangled, or somebody's replaced it with their own name, which was always my favourite version. Dead giveaway, every time.

And it kept showing up in the same place. Small Minecraft communities, mid-2010s, three kids trying to build a network, with a forum sitting at the middle of it that nobody had paid for. I spent years around vBulletin and XenForo as an addon developer, so I knew what those footers were supposed to look like. Once you know, you can't unsee it.

The tell is worth explaining properly though, because the reason it works says something about how commercial forum software was built — and because what those kids were actually taking on was a lot worse than they understood at the time.

Why the Copyright Line Is Load-Bearing

Free forum software doesn't care whether you credit it. Commercial forum software cares a lot, enough to build the credit into the product and then sell you the right to take it out again.

XenForo is the cleanest example because the pricing page just says it. Self-hosted licence, $195. On the hosted plans, "Branding free" is a paid add-on at +$30/month or +$360/year, and they describe it as removing "the XenForo copyright from public-facing pages."

Sit with that for a second. The vendor is telling you that people want the copyright gone, that enough people want it gone to make a product out of it, and that doing it legitimately costs more per year than the software did. So a XenForo forum with no XenForo copyright is one of two things: somebody paying a premium for a tidy footer, or somebody who took it out for free.

I never once met a Minecraft community paying $360 a year for a tidy footer.

vBulletin worked the same way, copyright living in the footer template, and the logic holds for anything that ties attribution to payment. Stripping it is the most visible edit a nulling distributor makes, because it's the edit the customer actually came for. Nobody downloads a cracked forum to admire the licence compliance.

That's exactly why it's such a good signal. The one change you can see from the outside is the one change every single nulled copy has.

The Other Tells

None of this needs anything clever. It's all just looking at a public website — which is the point, because if I can spot it in a browser tab, so can anyone scanning the whole internet at once.

A version that stopped moving. Commercial forum software updates through a licensed channel. So when you pull up a forum whose generator metadata, asset paths or JS bundles pin it to a release from four years back, on a product that's shipped security releases since, you're not looking at somebody who hasn't got round to it. You're looking at somebody who can't.

Cookie prefixes, with a caveat. Session cookie names help narrow down which product you're looking at, which is what tells you whether a missing copyright line means anything at all. Treat them as a hint and not an ID, though, because on the open-source side the admin can just change them. phpBB ships cookie_name as phpbb — that's straight out of schema_data.sql — and puts it in the control panel as an editable text field. MyBB builds every cookie off a settings value:

$cookie = "Set-Cookie: {$mybb->settings['cookieprefix']}{$name}=".urlencode($value);

So a forum whose cookies say nothing you recognise hasn't necessarily hidden anything. Might just be an admin who changed a setting. Corroborating evidence, not a verdict.

Leftover scaffolding. An /install/ directory still sitting there months after launch isn't a nulling tell as such. It's a tell about the person running the thing, and in my experience that's the same population.

Mismatched branding. Theme and plugin copyright gone but the core's still intact, or the other way round. Commercial add-ons got nulled way more often than cores did, because they were easier to find and nobody ever checks them.

I'm not cataloguing this so you can go hunting. I'm cataloguing it because this is what your forum looks like to somebody else, and the whole list takes five minutes to walk.

What You Buy by Not Paying

Here's the bit I think everyone underestimated, including me for a while: a nulled install isn't a licensed install minus the receipt. It's an install that can never be patched.

XenForo's own terms lay out the shape. A licence gets you lifetime use of the software plus "one year of access to support and software updates," and after that "a one-year extension must be purchased" to keep getting them. Updates come through an entitlement. Rip out the licence check and you've ripped out your own access to the update channel right along with the vendor's ability to enforce anything.

So the install freezes wherever it was when it got nulled. Every security release after that date isn't inconvenient to get. It's unavailable.

Want to see what that actually means? Take the one that defined this whole problem for vBulletin. CVE-2019-16759, published 24 September 2019: "vBulletin 5.x through 5.5.4 allows remote command execution via the widgetConfig[code] parameter" in an ajax/render/widget_php routestring request.

Forget the score, look at the vector. AV:N means over the network. AC:L means it's easy. PR:N means no privileges and UI:N means nobody has to click anything. No account, no login, no social engineering. One request to a public endpoint and you've got command execution. It went into CISA's Known Exploited Vulnerabilities catalog with exploitation marked active, which is the official way of saying people were already doing it.

And then it happened again. Palo Alto's Unit 42 documented a second flaw the next summer and were blunt about how it related to the first: "The exploits are a bypass of the fix for the previous vulnerability, CVE-2019-16759".

Their timeline is the part that gets me. "vBulletin released the patch to fix this vulnerability on Aug. 10, 2020." And: "We caught the first incident of CVE-2020-17496 exploitation on Aug. 10, 2020". Same day. The patch and the first real attack showed up together.

So if you were a licensed admin you had to apply two separate fixes inside eleven months, the second one because the first was incomplete, with attackers moving the day it shipped. That's the baseline a nulled install was up against. Not one missed patch — a run of them, on a clock somebody else was setting.

Now put that next to the licence problem. A vBulletin 5.x box nulled in 2018 is on the wrong side of both of those patches permanently. Not until someone gets round to it. Permanently, because the only road to either fix runs straight through the licence check that got removed.

That's the trade. You saved a licence fee, and in exchange you can never respond to a pre-auth 9.8 — or its sequel — for as long as that install exists.

If you want the longer story of why flaws like this kept coming out of that codebase, I wrote about vBulletin's architecture and its slow decline separately. The point here is narrower: whatever the vendor shipped as a fix, a nulled box couldn't take it.

The 97% Number

The second cost is the one you can't see from the footer. Somebody went and measured it.

There's a 2022 USENIX Security paper, Mistrust Plugins You Must: A Large-Scale Study Of Malicious Plugins In WordPress Marketplaces, where the authors built an automated detection framework and pointed it at nightly backups of 410,122 unique websites, covering around 5.7 million plugin installs going back to 2012. They turned up 47,337 malicious plugins on 24,931 unique websites.

Then they pulled out the nulled ones specifically. Of 8,776 nulled plugin instances across 6,223 websites, 8,525 carried malicious code — or as they put it, "over 97% of all nulled plugins deliver malicious behaviors."

Ninety-seven percent. That's not a worrying minority. That's basically all of them.

Two more numbers from the same paper deserve to travel with that one. "Pirated plugins cheated developers out of $228K in revenues" across what they measured — which is the small number, and the one everybody assumes is the whole story. And "over 94% of these malicious plugins are still active today," with 23,577 of those 24,931 infected sites still infected when the paper was written. Nobody noticed. That's the part that should bother you. These weren't sites that got owned and cleaned up. They got owned and stayed owned.

One honest caveat: that study is WordPress, not forum software. I'm not going to pretend measuring one ecosystem measures another. What does carry across is the distribution economics, which are identical — same nulled marketplaces, same anonymous repackagers, same business model where the thing is free because you're not the customer. Nobody has done an equivalent large-scale study on nulled forum software. If the rate over here is dramatically better, I haven't seen anyone show it.

And honestly the mechanism is obvious once you say it out loud. Nulling means editing the source. Somebody has already been in this code, for their own reasons, before handing it to you for nothing. The licence check is the edit they're advertising. Whether it's the only edit is not a question you get to answer by looking at the footer.

For the same trade in consumer form, the fake GTA 6 ISO is exactly this: the thing you wanted, free, from someone with no reason to give it to you.

What a Grep Actually Finds

That 97% is a population statistic. On your own box it collapses into something you can answer with one command — as long as you know what the command is looking for.

Obfuscated PHP backdoors are a decoder plus an evaluator, basically always. On their own base64_decode and gzinflate are boring data functions, and eval is a language construct with legitimate if regrettable uses. Put a decoder inside an evaluator and you've got exactly one thing: code execution coming out of data, which is the entire job of a backdoor. Whoever planted it needs the payload to survive someone skimming the file, and a base64 blob does that nicely.

So what you're hunting is the combination, not the individual functions:

grep -rnE "eval[[:space:]]*\(|base64_decode|gzinflate|str_rot13|create_function|shell_exec|passthru" \
  /path/to/forum --include='*.php'

I built a three-file test tree to check this actually behaves — two ordinary forum files plus one with the shape of an appended backdoor, payload decoding to echo "benign demo";. One line came back:

testforum/inc/plugins/suspect.php:3:eval(base64_decode("ZWNobyAiYmVuaWduIGRlbW8iOw=="));

Nothing on either clean file. That's the useful bit — on a legitimate forum codebase this pattern stays quiet, so whatever hits you do get are worth actually reading instead of triaging a wall of noise.

One refinement, because the obvious dodge is splitting the function name up so a literal search sails past it:

grep -rnE '"[a-z]{2,4}"[[:space:]]*\.[[:space:]]*"[a-z]{2,4}"' /path/to/forum --include='*.php'

That catches $fn = "ass" . "ert"; and friends. Noisier than the first one, since ordinary code concatenates short strings all the time, but on a forum's PHP it's a short enough list to read.

Neither of these is an audit. Anything careful enough won't look like either pattern, and whatever you find is the floor and not the ceiling. The point is that the cheapest check available is one line long, and I'd bet almost nobody running a nulled install has ever run it.

The Nulled Install Is a PHP Time Capsule

Here's the second-order thing nobody writes about, and it's the one that compounds on you.

The obfuscation primitives that vBulletin-3-and-4-era code leaned on are gone from modern PHP. I measured this on PHP 8.3.6:

Three of the era's favourite ways to execute a string just don't work any more. The assert() row is the one I'd look at twice: it fails not because assertions got switched off but because PHP 8 stopped treating the argument as code at all, so turning assertions back on doesn't bring the vector back. I checked, because I assumed the opposite.

All of which sounds like good news right up until you follow it through.

A nulled forum from that era needs a PHP old enough to run it. Not prefers — needs, because the install can't be updated to a version that works on PHP 8, since updating is the exact thing the nulling took away. So the operator pins PHP, and php.net's end-of-life list tells you what that means:

Only 8.2 and later get anything at all today, and 8.2 is on security fixes only until the end of this year.

So follow the chain: no licence, so no forum updates, so a forum that needs an ancient PHP, so an unpatched interpreter sitting underneath the unpatched application. One decision at the top, two layers of permanently unpatched software at the bottom. Everyone thinks about the forum CVE. The PHP one is bigger and I've never heard anybody bring it up.

The Option That Was Already Free

Everything so far is what nulling costs. Worth putting the alternative next to it, because it was sitting right there the whole time and it was free.

Nulling means removing a licence check, so software without a licence check has nothing to remove. phpBB ships under the GNU General Public License v2 and SMF under a BSD-three-clause licence whose conditions you satisfy by keeping a copyright notice in the source. Run either one on a hundred forums, commercially, forever, for nothing. There's no key for anyone to withhold.

MyBB sits a little differently, and this is a small thing I only noticed while fact-checking myself. Its homepage calls it "free and open source forum software" and names no licence anywhere. Its source headers say Copyright 2010 MyBB Group, All Rights Reserved and point at a licence of its own. Both can be true — projects describe themselves loosely and license themselves specifically — and either way the practical result is the same: no key, no activation, nothing to crack. But it isn't GPL, and I'm not going to claim permissions when I haven't read the text.

So: no nulled phpBB, no cracked SMF, no nulled MyBB. The nulled market exists for the commercial tier — vBulletin, XenForo, Invision — and much more often for commercial themes and add-ons, whatever core happens to be underneath.

Where MyBB Actually Landed

From what I saw, MyBB ended up the default for three overlapping crowds: hacking and cracking communities, the script-kiddie tier underneath them, and people who either hadn't heard of nulling or had heard of it and decided no thanks.

That last group was reasoning correctly. The middle group was reasoning more cleverly than anybody gives them credit for. Think about the choice if your forum's entire value is that it can't be traced back to you:

Put like that, MyBB isn't the compromise. It's the correct answer to that threat model. Nothing to subpoena, no third party who's already shown they'll edit the source, and a codebase you can read end to end if you care. If your board is full of people who understand that the user table is the asset, trusting a stranger's repackaged XenForo is an obviously terrible trade — and buying a licence is worse, because now there's a paper trail with your name on it.

What people describe as nulled first, MyBB second was really two different risk appetites landing in two different places. The ones who nulled wanted the product. The ones who picked MyBB wanted deniability.

Free and Patchable Is Not Safe

Where that reasoning falls over is assuming the free option is therefore secure. It isn't, and MyBB's own security release log is the plainest evidence going. Six of the ten releases it lists:

Two remote code execution fixes in that stretch, and the two most recent releases closed eighteen and twenty-four issues between them. That's not a quiet codebase. It's a maintained one.

I want to be precise here because the words get thrown around loosely. MyBB is not safer than XenForo. It's patchable — the fixes exist, they're free, and applying them costs you nothing but attention. The nulled XenForo next door can't take a patch at any price. A MyBB box four security releases behind is in roughly the same practical spot as that nulled XenForo. The difference is it got there through neglect instead of architecture, which means somebody can fix it on a Tuesday afternoon.

And it aged, which is the kinder thing to say about it. Among the free options MyBB was the good one — next to phpBB's committee austerity and SMF's functional plainness it felt considered. The admin panel made sense. The templates were legible. For a forum in 2006 that was the right answer and it cost nothing, which is a combination you don't get often.

What happened to it wasn't really failure. It was a change in what a forum got compared against. By 2010 threaded conversation was already leaving dedicated boards. By 2015 the comparison was Discord. Load a default MyBB install now and it reads as a period piece, because that's exactly what it is — it looks like well-built 2008 software, and it is well-built 2008 software.

Which is the running joke of this whole subject, and the thing I keep coming back to. The people nulling XenForo were chasing the product that looked modern, and paid for it with an unpatchable install and roughly a one-in-thirty-five shot at clean add-ons. The option they walked past looked dated and would have patched cleanly for the next fifteen years. The open-source three went their own ways and every one of them is still patchable today, which is more than the nulled XenForo can say.

The Minecraft Network Pattern

The reason this clustered around Minecraft communities isn't mysterious. It's economics.

A server network in that era needed a forum. Not wanted — needed. It's where applications went, where ban appeals went, where the rules lived, where the donation tiers got advertised. The expected shape of a serious network included one, and XenForo was visibly the nicest thing on the shelf.

The people building these were usually teenagers with a server, a Discord, and donation income somewhere in the low tens of dollars a month. Against that, $195 plus renewals wasn't a line item, it was impossible. The nulled copy wasn't a considered risk decision. It was the only road they could see to the thing that looked professional.

What made it worse than some hobbyist blog running the same software is everything else that lived on that box.

These networks handled real money. Donation stores took PayPal, and store plugins handed out in-game ranks off payment callbacks. The same person ran the forum, the store integration and the game servers, usually on one machine, usually as one user.

And the accounts got reused. Forum password, store password, sometimes the Minecraft account email, very often the same password the player used everywhere else — because they were thirteen. A forum breach there wasn't a forum breach. It was a credential dump against a population who'd used that password on everything they owned.

So picture the stack: an unpatchable commercial forum of unknown provenance, running next to a payment integration, holding credentials for a community of minors, administered by somebody who couldn't afford the software and definitely couldn't afford an incident response. And the only externally visible symptom of all of it was a missing line in the footer.

If you run a game network now, the plugin supply-chain problem is this same argument pointed at the server side — trustworthy-looking code from a channel nobody verified, running with full privileges.