The truth about the vBulletin forums MySQL security flaw

Updated happygeek 1 653 Views

Many of the biggest forum-based online communities, including DaniWeb, are powered by vBulletin software. So it came as something of a shock when the BBC reported that a . But is the security flaw really both that simple and that serious, and are DaniWeb users at risk?

Let's answer the most important question first: No, DaniWeb users are not and have never been at risk from this security flaw as it only impacted upon a specific new version of vBulletin that was released on the 13th July and which DaniWeb has not upgraded to.

Which brings us to the simple and serious part. While the flaw, which exploits sites using version 3.8.6 of the vBulletin software only, is very simple indeed the seriousness of the problem has, in my opinion, been somewhat exaggerated. The flaw is specific to the FAQ section of that vBulletin version, and could be exploited simply by typing a keyword into the FAQ search box which then exposed MySQL database credential data. I will not be revealing any more than that as there are still plenty of forums out there which have not updated to the fully patched and secured version of vBulletin as I write this.

How do I know that? Because another really simple Google search for the vBulletin copyright message reveals them in a matter of seconds. So that would suggest that this is, indeed, a serious security breach waiting to happen. Yes? Actually, things are rarely that clear cut in the world of online security if you take the time to avoid the knee-jerk reaction and investigate a little deeper, and this is a case in point.

Although many of the reports I have seen so far regarding this problem state in big headline-sized letters that the flaw reveals vBulletin admin logins, this would appear not to be the case. The actual problem is no less worrying, unfortunately, as the flaw exposes MySQL database credentials such as MySQL usernames, MySQL passwords and MySQL port numbers. In the wrong hands, and with a specific set of technical circumstances, such data would be just as catastrophic of course. But it is the detail of those specifics which are key to getting a real world grasp on how serious the flaw is, at least in terms of actual data being vulnerable if not in terms of it existing in the first place.

Those specifics are then, according to , when "phpMyAdmin is installed with db authentication mode" who noted in a series of posts on Twitter that under such circumstances "the leaked MySQL credentials are calamitous".

Let's recap then: if vBulletin is leaking your MySQL database credentials while phpMyAdmin is in database authentication mode would, without any doubt, hand over complete access to the vBulletin forum database to a malicious user. So, even though for the most part this forum security flaw has been rather overblown by the media as the MySQL credentials will be pretty unusable because most hosts only expose MySQL to localhost, there is a particular circumstance where it is particularly serious.

However, while this does make this less of a real world risk to most forums and their users, it does not dilute the seriousness of allowing the vulnerability to exist in that new software version in the first place. Reports have suggested that the flaw enables 'script kiddies' to access database credential data, but I would suggest that it was a coding error of schoolboy dimensions that enabled the flaw to exist in the first place. Does Internet Brands, which acquired vBulletin back in 2007, not have some kind of security auditing process in place? Surely it was not too much to expect such a simple mistake to be picked up and corrected before pushing this update out to customers? To be fair, Internet Brands did react quickly to issue a patch within hours of being made aware of the flaw, but that does not mitigate the fact that it should never have existed in the first place.

Users of vBulletin 3.8.6 can update to Security Patch vBulletin 3.8.6 PL1 here . The existing vbulletin-language.xml file needs to be deleted from the 'install' directory, and the new one uploaded to it in ASCII format. Then both includes/version_vbulletin.php and install/vbulletin-language.xml from the patch need to be uploaded. Finally, users must enter the Admin Control Panel and run: Admin CP -> Languages & Phrases -> Download/Upload Languages -> Import Language XML File and click import. To verify that the patch has been applied go to Admin CP -> Language & Phrases -> Search in Phrases -> Search for Text: database_ingo -> Phrase Variable Name Only (checked) -> Find and search for 'database_ingo' which should have been removed.

Thankfully, users who upgrade to vBulletin 3.8.6 from an earlier version will not need to worry about the manual upgrade process as the download package has now been patched.

vBulletin.jpg 63.62 KB

Dani AI

Generated

Brief, practical follow-up to ’s excellent breakdown (and to note ’s off‑topic praise): a compact triage + hardening checklist for forum operators and hosts that avoids repeating the original vulnerability narrative and focuses on concrete, actionable steps and small commands for detection, containment and recovery. (isc.sans.edu)

Immediate triage and evidence preservation: snapshot the site and collect logs before making changes, isolate the affected host (network block or take offline), and preserve copies of webserver, PHP and database logs for forensic review. Example commands for collection and quick indicators-of-compromise (file changes, suspicious PHP code, unusual requests): 

sudo tar -czf /tmp/site-snapshot-$(date +%F).tgz /var/www /var/log/apache2 /etc
find /var/www -type f -mtime -30 -ls
grep -R --line-number -E "eval\\(|base64_decode\\(|gzinflate\\(" /var/www || true
grep -Ei "search|q=" /var/log/apache2/access.log* | tail -n 200

These steps follow standard incident‑response practice (identify, contain, preserve evidence, eradicate, recover). Keep raw evidence immutable and document every action. (csrc.nist.rip)

Containment and recovery priorities: assume credentials might be exposed until proven otherwise — revoke/rotate database and admin credentials, invalidate active sessions, rotate API keys, and restore from known‑good backups or rebuild from trusted images when compromise is suspected. Reduce blast radius by giving web applications narrowly scoped accounts; example minimal MySQL user:

CREATE USER 'forum_app'@'127.0.0.1' IDENTIFIED BY 'S3cureP@ss!';
GRANT SELECT, INSERT, UPDATE, DELETE ON forumdb.* TO 'forum_app'@'127.0.0.1';
FLUSH PRIVILEGES;

Principle of least privilege and moving secrets out of web‑accessible folders are core defenses. (cheatsheetseries.owasp.org)

Longer‑term hardening: run timely updates from vendors, use defense‑in‑depth (WAF, IP restrictions or VPN for admin panels, MFA for accounts where possible), remove leftover debug/install files, schedule integrity scans and log monitoring, and test patching in staging before production. If signs of compromise are found, preserve evidence, perform a full IR workflow, and consider professional DFIR assistance for complex breaches. (csrc.nist.rip)

Member Avatar for Bruce100
Bruce100 0 Newbie Poster

These are the Dani Web forums that the topics are so interesting that we are in the high and it is all of the great demand.

Edited by Dani because: Plug snipped
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview