phpBB vs. SMF vs. MyBB: Three Very Different Fates

Part 1 of this series was about vBulletin, a piece of commercial software that got acquired, mismanaged, sued its own former developers, and is still generating critical CVEs sixteen years after the community that built it walked away. I built plugins for that platform and lived through its decline from a hosting company's support desk. This entry is different, and I want to be upfront about that difference before diving in: phpBB, Simple Machines Forum, and MyBB were never my daily tools the way vBulletin and XenForo were. I was in their communities, I ran a couple of them for side projects over the years, and I've audited more than one client installation of each during SudoSecurity engagements, but I didn't build a career writing addons for any of the three. What follows is researched with the same rigor as everything else on this site, not narrated from a decade of hands-on plugin work the way Part 1 was.

This distinction matters for a specific reason: all three of these platforms were free from day one, or became free early enough that the distinction barely registers now, which makes them the natural counter-argument to Part 1's thesis. If vBulletin's decay traces back to a corporation buying software it didn't understand and mismanaging the incentive structure underneath it, you'd expect three community-driven, non-commercial forum platforms to have aged better. Two of them did. One of them, as of this June, posted a CVSS 9.8 authentication bypass that lets an unauthenticated attacker take over any account, including administrators, on a completely default installation. "Free and open source" was never the variable that mattered. Something else was, and figuring out what means going through all three platforms individually before the comparison means anything.

phpBB: The One That Got Wormed by Google Itself

phpBB started in June 2000, when a developer going by "theFinn," James Atkinson, built a UBB-style forum script for his wife's website. Two other developers, Nathan Codding and John Abela, joined shortly after, and the project moved to SourceForge, where it caught on fast enough that by early 2001 the team had already outgrown the original codebase and started a full rewrite. phpBB 2.0.0 shipped April 4, 2002, under the GNU GPL v2 from the start, no ambiguity, no later license migration story the way two of the other platforms in this piece have. That single decision, full open source licensing from the first stable release, is worth holding onto, because it's going to look different by the end of this piece than it looks right now.

phpBB2 became enormous. It's the version most people who used a forum in the mid-2000s remember, and it's also the version responsible for one of the more inventive pieces of malware in web security history. In November 2004, a vulnerability was disclosed in phpBB2's viewtopic.php: the highlight parameter, meant to bold search terms in a thread, passed user input through urldecode() and then into a function that could be coerced into executing arbitrary Perl or shell commands. phpBB shipped a patch a month later, in version 2.0.11. Most installations didn't apply it, for the same reason most installations never apply a patch on any platform: the forum kept running fine, nobody noticed the advisory, and "patch it eventually" quietly became "never patch it at all" the way it always does when nothing visibly breaks in the meantime.

We recommend reading The Decline of Stack Overflow if this pattern of community platforms slowly losing the plot feels familiar from a different angle. It's a different mechanism, community trust eroding instead of code aging, but the same underlying lesson about what happens when a platform's governance stops keeping pace with what its users need from it.

On December 20, 2004, a worm called Santy started using that unpatched window in a way nobody had quite seen before. Instead of scanning IP ranges or maintaining its own list of targets, Santy queried Google directly, searching for allinurl:"viewtopic.php" combined with a randomized string to get varied result pages, then parsed the search results to find live phpBB installations and fired the highlight exploit at each one. F-Secure and Kaspersky both tracked its spread in real time: thirty to forty thousand sites defaced within twenty-four hours, with security researchers describing it as the fastest worldwide worm propagation they'd measured to that point, three hours from release to global spread. Every infected site got the same message stamped across its writable files: "This site is defaced!!! NeverEverNoSanity WebWorm generation X." Google started filtering the worm's own search queries on December 22 to choke off its targeting mechanism, and variants quickly emerged that switched to Yahoo, AOL, and regional Google domains to route around the block, with one variant, Santy.C, expanding past phpBB entirely to attack any PHP script vulnerable to file inclusion.

Sit with the mechanism for a second, because it's a different failure mode than anything in Part 1's vBulletin story, and it's worth being precise about why. Santy didn't need to build or maintain its own reconnaissance infrastructure, the kind of scanning fleet a traditional worm has to run and hide to find its next targets. It borrowed Google's, for free, at Google's own expense, turning a search engine's own indexing of the public web into an attacker's targeting system. Every phpBB installation that let Google crawl and index its viewtopic.php pages, which is to say nearly every phpBB installation, since indexability was the entire point of running a public forum, had effectively published its own list of exploitable endpoints to the one search index every attacker already had free access to. That's not a phpBB-specific flaw. It's a lesson about any system that makes its own vulnerable state publicly discoverable through a predictable URL pattern, and it's a lesson that generalizes past 2004 far better than most security folklore from that era does. The same logic underwrites modern "Google dork" reconnaissance against exposed admin panels, leaked credentials, and misconfigured cloud storage buckets today, minus a self-propagating worm doing the searching automatically.

phpBB kept moving. phpBB3, initially planned as a 2.2 release before the team recognized the scope of the rewrite and renamed it, shipped December 13, 2007, code-named Olympus, following a security audit by SektionEins before release. James Atkinson himself resigned from the project that same year, in April, citing personal circumstances. The team kept building: a Phar deserialization vulnerability, CVE-2018-19274, let an attacker who'd already compromised the admin panel escalate to full remote code execution by exploiting how PHP's phar:// stream wrapper triggers object deserialization the moment any filesystem function, file_exists() among them, touches a phar-formatted path, without the developer ever calling unserialize() directly. That's the exact PHP Object Injection family Ghost Check's first entry walked through in depth, wearing a slightly different disguise: the dangerous deserialization doesn't need an explicit unserialize() call in your own code at all if an attacker can get phar metadata parsed through a function nobody thought to treat as risky.

And then, this June, two critical authentication bypasses landed within days of each other. The first, tracked by Pentest-Tools.com as PTT-2026-004 with a 9.4 CVSS score, let an attacker take over any account with nothing but that account's username, which is trivial to obtain since phpBB's default member list is public. Every version up to 3.3.16 was affected in the software's default database-authentication mode, meaning a completely stock installation, no OAuth configured, no unusual settings touched, was exposed out of the box. The second, CVE-2026-48611, hit the OAuth verification path specifically: a broken state-verification check let an unauthenticated attacker hijack any account, administrators included, even on installations where OAuth login had never been enabled at all. Security researchers at Aikido traced the underlying authentication weakness in that code path back to roughly 2014, over a decade of latent architectural fragility sitting quietly in a codebase that had, by every other visible measure, been actively and responsibly maintained the entire time.

That last detail is the one worth sitting with longest. phpBB did almost everything right by conventional open source standards: full GPL from day one, continuous active development, a real security audit before its major rewrite, a volunteer team that's kept shipping patches for a quarter century. None of that prevented a decade-old authentication design flaw from sitting undiscovered until a professional pentesting firm found it in 2026. Good process reduces the odds of this happening. It doesn't reduce them to zero, and a project that's done nearly everything by the book still isn't immune to the same category of mistake that sank a corporation-owned competitor.

phpBB's development community outgrew its founders almost as fast as the software outgrew its own codebase. All development discussion, then and now, happens at a hub the community calls Area51: the bug tracker, the development wiki, continuous integration tooling, and the open door for anyone who wants to contribute code, all in one place, a level of process transparency vBulletin's plugin ecosystem never had because there was no public bug tracker to speak of for the stored-PHP hook system Part 1 covered. The phpBB2 era ran on what the community called MODs, community-submitted patches distributed as diff files that admins applied by hand against their own core installation, a more dangerous distribution model than vBulletin's database-stored plugins in one specific way: a MOD touched your actual source files directly, and two MODs that happened to edit the same block of code without knowing about each other would silently corrupt your installation the moment you installed both. phpBB3 replaced that entirely with a real Extensions system, sandboxed, versioned, hookable through defined events instead of raw file patching, plus a separate Styles system for anything visual. The current Customisation Database organizes that ecosystem into real categories you can browse today: cosmetic extensions, security tools, anti-spam, communication features, upward of 700 community-submitted styles split across dark, light, Prosilver-based, and Subsilver2-based variants. phpBB even runs its own Google Summer of Code program most years, a level of institutional continuity that a lot of "dead" software from this era never had in the first place.

Simple Machines Forum: Born From a Licensing Fight, Settled Into One of Its Own

SMF's origin story starts somewhere else entirely, with a piece of software it isn't: YaBB, Yet Another Bulletin Board, a flat-file Perl forum script a seventeen-year-old Dutch student named Zef Hemel released under the GPL in July 2000. YaBB caught on the way phpBB did, and in 2001 Hemel handed project management to Jeff Lewis, whose company later became central to this story. Not long after, developers Joseph Fung and Jeff Lewis spent a weekend porting YaBB from Perl to PHP, producing YaBB SE, which inherited a fair share of the original's resource and security problems along with its popularity.

What happened next is the part of SMF's history that reads less like software development and more like a contract dispute. YaBB SE 2.0 development stalled amid genuine copyright confusion: multiple unauthorized forks kept the YaBB SE name, and at least one developer built a commercial product from the codebase under a different name without crediting the original team. One of the newer contributors started what the project's own internal history describes as a "Secret Project," a from-scratch rewrite meant to strip out the accumulated cruft and rebuild the security and performance story from the ground up. The team adopted it as the real successor and, specifically to stop the brand confusion with YaBB, rebranded it Simple Machines Forum. Lewis Media, Jeff Lewis's company, stepped in with copyright lawyers to formalize the project's legal footing and wrote a custom license, the Simple Machines License, that governed SMF 1.0 and 1.1. SMF 1.0 shipped in 2004, and by 2007 the community had grown to 100,000 registered members on simplemachines.org.

In October 2006, the project took a step that separates its governance story from every other platform in this series: SMF split off from Lewis Media entirely, and the copyrights transferred to a newly formed non-profit membership corporation, Simple Machines LLC, with the stated purpose of committing to free software "without the perceived risks of corporate influence." Read that against Part 1's vBulletin story and the contrast writes itself. vBulletin went from community-built to corporation-owned and never came back. SMF went from a for-profit company's custom license straight to a non-profit specifically built to make sure that never happened to it. The organization operates today as a Nevada-registered membership corporation, with a small volunteer leadership structure and a lead developer known in the community by the handle Sesquipedalian rather than a corporate title.

That governance structure shows up directly in how SMF's customization ecosystem is organized. The official Simple Machines Customization Site splits cleanly into a Theme Site and a "Mod Site," community terminology that's stuck around since the earliest days, and the community forums built around them are still enormous: as of this year, SMF's own community board reports nearly four million posts across almost half a million topics from over 460,000 registered members, numbers that put a lot of software people assume is "dead" to shame. That said, this section shouldn't read like an uncomplicated success story, because the community itself doesn't universally agree it is one. A frequently cited critical review of the platform describes SMF's plugin integration system as "a really weird integration system which is more likely than not to break the entire forum between minor updates," a specific complaint rather than vague griping, and one that lines up with SMF's unusually long major-version release cadence, often a decade or more between significant rewrites. A healthy community and a technically dated architecture aren't mutually exclusive, and SMF is a working example of both being true about the same piece of software at the same time.

The part that separates SMF's licensing story from where it started is that the custom license didn't stick either. SMF 2.0 and every version since moved to the 3-clause BSD license, plain, well-understood, open source with none of the ambiguity a homegrown license carries. That's a genuine reversal in its own right: a project that started with a legally custom-drafted license born out of a trademark and copyright dispute, ending up on one of the most standard, permissive open source licenses that exists, on top of the governance reversal from the previous section. Two separate course corrections, both pointing the same direction, away from exactly the kind of ambiguity and control vBulletin never managed to escape.

SMF's security history reflects that governance path about as directly as a codebase's CVE list can reflect anything. Its older versions carried the standard mid-2000s PHP forum bugs: SQL injection through display names and HTML entities, CSRF against admin actions via image file vectors, XSS in the news management system, a file disclosure bug in versions through 2.0.3 that let untrusted "co-admins" read settings.php and pull database credentials, a dangerous trust-boundary failure for any deployment sharing admin access across parties who don't fully trust each other, structurally the same mistake as the co-admin problem, applied to configuration files instead of database rows. But its more recent entries in the CVE record look different in character. Recent reports against SMF 2.1.4 involve authenticated administrators triggering XSS through the news and attachment management panels, several explicitly marked "disputed" by the vendor on the grounds that the reporting party already needed privileged access before the flaw was reachable at all. That's a meaningfully lower bar of severity than phpBB's pre-authentication account takeover or the RCE chains running through vBulletin and, as the next section covers, MyBB. Whether that's the direct product of SMF's move to a standard open license, a smaller and more stable feature surface that gives attackers less to work with, or plain good fortune in which bugs got found and reported first is a harder causal claim to make cleanly than a tidy narrative would like, and I'd rather flag that plainly than force a conclusion the data doesn't fully support.

MyBB: The One That Stayed Proprietary the Longest and Never Finished the Next Version

MyBB's history inverts the usual open source origin story in a way that's easy to miss if you assume "free forum software from the 2000s" all started from the same set of values. Chris Boulton founded the project in 2002 as DevBB, a fork of an earlier board called XMB, and the first public release candidate went out in December 2003. MyBB 1.0 didn't ship until December 2005, and for the entire stretch between founding and late 2008, the software was free to use but developed under a proprietary license, with development itself happening on a closed internal cycle the public had no visibility into.

That changed on October 12, 2008, with the 1.4.2 release, when MyBB switched its license to the GNU GPL v3. The push, notably, didn't come from inside the project. It came from KDE, which wanted to launch a MyBB-powered community forum as an alternative to a mailing list and needed the licensing terms to qualify as open source before adopting it. Even after the license changed, it took until August 2009 for the MyBB Group to open real development access, giving the public read access to the bugtracker and the subversion repository for the first time. Chris Boulton stepped back from day-to-day leadership in May 2009, handing responsibilities to Dennis Tsang.

That closed-development history left a mark that's still visible today. MyBB 2.0 has been in development, in some form, for well over a decade, promised at various points as a from-scratch rewrite addressing exactly the architectural debt this series keeps finding underneath every one of these platforms, and as of the most recent reporting there's still no confirmed release date, with the team's stated focus shifted toward sustaining the current 1.8.x branch rather than finishing the next major version. That's a different failure mode than anything else in this piece: not a corporate capture, not a single catastrophic security architecture flaw, but an open source project whose governance never fully recovered from years of closed, founder-controlled development, leaving it stuck maintaining an aging branch instead of shipping the rewrite everyone's been waiting on since roughly 2015.

And that aging branch has had a rough couple of years. MyBB logged eleven published vulnerabilities in 2025 alone, at an average CVSS score of 7.0, more than triple the volume of the year before. The most technically interesting of the batch is a chained privilege escalation across CVE-2025-48940 and CVE-2025-48941: an authenticated administrator, working through the software's own admin panel, can modify upload path settings, upload a malicious PHP file disguised as an avatar image, and then use the language configuration editing interface to get that file included and executed on the server, walking from an already-privileged account to full remote code execution through three separate admin features that were never individually dangerous but combined into a complete chain. Add a stored XSS vulnerability in the announcement system, a SQL injection through the Copy Forum feature, and a search-permission bypass that let attackers infer the existence of hidden threads by content, and you get a pattern that looks less like one catastrophic architectural flaw and more like a maintenance team stretched thin across a codebase that's been patched forward for two decades without ever getting the clean-slate rewrite it was promised.

MyBB's plugin system, to its credit, got one thing right from early on that both of its stalled years never undid: hooks distributed throughout the core PHP code let a plugin add or change functionality, admin control panel pages included, without editing a single core file, the same non-destructive principle phpBB3's Extensions system reached for and vBulletin's raw database-stored PHP never had in the first place. That architectural choice outlived the years of closed development around it, which tells you the underlying engineering was sound even while the governance around it wasn't. The community's official hub for finding that work, Extend MyBB, hosts the plugins, themes, and translations the "active and friendly" community, in the project's own words, keeps producing, and MyBB has since added a Discord server alongside its traditional community forums, the same platform migration eating into standalone forum communities generally, showing up even inside the software built to be a standalone forum itself.

What Explains the Divergence

Three platforms, same starting premise, same language, same decade of origin, three different outcomes: phpBB did nearly everything by the book and still got hit with a decade-old authentication flaw this June. SMF resolved its own licensing chaos into genuine open governance and has, so far, the quietest recent CVE record of the three. MyBB spent its formative years under closed, founder-controlled development, opened up only under external pressure, and has spent the years since patching an aging codebase it never finished replacing.

We recommend reading The PHP Community and Development Sucks next if you want the unfiltered version of why so much PHP infrastructure, forums very much included, ends up in exactly this position. It's the same pattern from a different vantage point: tutorial-era shortcuts and unexamined architecture choices that felt harmless in year one and become someone else's decade-long liability by year fifteen.

The honest comparison across all four platforms in this series so far, phpBB, SMF, MyBB, and vBulletin from Part 1, doesn't support a simple story where open source wins and commercial software loses, or where any one governance model guarantees a safe outcome. What it supports is narrower and less satisfying: architectural debt from a project's founding era keeps generating consequences years or decades later regardless of who owns the code, and the thing that seems to matter most is whether a project ever got the resources and organizational stability to do a real clean-slate rewrite once its founding architecture's limits became visible. XenForo got that rewrite, funded by founders who left specifically to build it properly. SMF got it, twice, first architecturally and then legally. phpBB got a partial one with phpBB3, enough to survive but not enough to catch a thirteen-year-old authentication design flaw before a paid pentesting firm did. MyBB never got one at all, and MyBB 2.0's decade-plus of vaporware status is exactly what that absence looks like from the outside.

There's a second variable worth naming separately from the rewrite question, because it explains something the rewrite framing alone doesn't: who's looking for these bugs, and why. phpBB's two 2026 disclosures came from a commercial penetration testing firm and an AI-driven security research outfit, professionals paid to go looking, not volunteers stumbling across a bug during unrelated maintenance work. MyBB's 2025 surge tracks closely with increased attention from bug bounty platforms and automated vulnerability scanning services treating aging PHP forum software as a target-rich environment precisely because it's still widely deployed and rarely rewarded with the same scrutiny newer frameworks get. SMF's comparatively quiet recent record might reflect sturdier code, or it might as easily reflect a smaller, less commercially interesting install base that attracts less of that paid attention in the first place. A codebase's public CVE count says as much about who's currently paid to look at it as it says about how many bugs are sitting there waiting to be found, and that's a harder variable to control for than architecture alone, no matter how satisfying a purely architectural explanation would be to end this section on.

Choosing a Forum Platform Today

If you're picking infrastructure for a community right now, whether that's a self-hosted forum, a Discord server with a bot doing the heavy lifting, or a proprietary SaaS platform you're trusting with years of institutional knowledge, the four platforms across this series so far all point at the same question, and it's not "is this open source" or "is this actively maintained." It's "does this project have a credible path to a real architectural rewrite the next time its founding assumptions stop holding," and most platforms, including some of the ones you're evaluating today, don't have a good answer to that question until the day they desperately need one.

Four platforms into this series and the throughline hasn't changed: nobody sets out to build the vulnerability that gets disclosed in 2026. They build something reasonable for 2000, or 2002, or 2004, under whatever constraints and incentives existed at the time, and the bill comes due whenever the gap between "reasonable then" and "safe now" finally gets tested by someone with the patience to look for it. Part 3 of this series is still forming. If you've got a platform from this era you want the same treatment, the comment section knows where to find me.