# Your Database User Should Not Be root 1. [Home](https://mysites.guru/) 2. [Tools](https://mysites.guru/tools/) 3. [Database integrity](https://mysites.guru/tools/database-integrity/) 4. Your Database User Should Not Be root # Your Database User Should Not Be root ![Your Database User Should Not Be root](https://mysites.guru/_astro/database-user-is-root.Dmd7mAR3_y1Bp2.webp) Only 0.1% of sites get this wrong, but the failure is total. A root database user means one SQL injection reaches every database on the server. Article Contents - [How the root database user check works](#how-the-root-database-user-check-works) - [How one SQL injection becomes a whole-server breach](#how-one-sql-injection-becomes-a-whole-server-breach) - [The privileges a database user should actually have](#the-privileges-a-database-user-should-actually-have) - [Creating a limited MySQL user for Joomla](#creating-a-limited-mysql-user-for-joomla) - [Why the root user swap isn’t one-click](#why-the-root-user-swap-isnt-one-click) - [Further Reading](#further-reading) - [Frequently Asked Questions](#faq) How common is this? - 0.1% of the Joomla sites we have this data for fail this check. Platform: Joomla. Measured across the sites we audit, on each site's most recent snapshot. ## How the root database user check works Joomla stores the database username it connects with inside `configuration.php`, in plain text. This check reads that value and flags one specific case: a database username of `root`. It is one of a family of automated database checks mySites.guru runs on every snapshot; see [how to check Joomla database security](https://mysites.guru/blog/how-to-check-joomla-database-security/) for the fuller picture. ## How one SQL injection becomes a whole-server breach This is a rare failure, not a common one. It shows up on roughly 0.1% of the Joomla sites we audit, so if you are reading this because your own check passed, this is not where your attention needs to go. But rare is not the same as unimportant. Where it does happen, the consequence is about as bad as a database misconfiguration gets. MySQL’s `root` account is not scoped to a single database. It is a server-wide superuser: it can read, write, create, alter and drop every database on that MySQL server, not just the one Joomla was set up to use. It also has privileges that have nothing to do with data at all. The `FILE` privilege, which a root-level account normally has, lets a connected user read arbitrary files off the server’s disk with `LOAD_FILE()` and write files back out with `SELECT ... INTO OUTFILE`, entirely outside of any database. In practice that means a SQL injection flaw combined with a root database connection is not just a data breach; it can be a path to reading `configuration.php` on every other site on the box, or writing a new file straight onto the server’s disk. Most shared hosting boxes run several customers’ databases side by side on the same MySQL server. If your Joomla site connects as `root` and something exposes those credentials, an attacker does not just get your Joomla data. Depending on how the host has isolated accounts, they can potentially reach every other database on the same server too. This is one reason the failure rate for this check is as low as it is: most hosts either refuse to hand out root credentials for anything but server administration, or restrict which hosts and accounts the root user is even allowed to connect from, so the door is closed before Joomla is ever installed. Where it is not closed is usually a smaller VPS or self-managed server, where whoever set it up took the path of least resistance and used the one account they already had. Credentials get exposed in ways that have nothing to do with Joomla being weak. A misconfigured backup leaves `configuration.php` downloadable. A separate vulnerable extension allows local file inclusion. A different site on the same server gets compromised first and its own weak point is used to pivot. In any of those situations, the difference between a scoped database user and `root` is the difference between “one site’s data is exposed” and “the entire server is exposed.” There is a second, quieter risk. An attacker who reaches a `root` connection can create their own database users with the same superuser privileges. Even if you notice the compromise and change the `root` password, a second account they created earlier can still get them back in, because you were never looking for it. ## The privileges a database user should actually have A dedicated database user, created specifically for this site, with privileges scoped to only the single database Joomla needs: `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `DROP`, `ALTER` and `INDEX`. Some extensions also need `CREATE TEMPORARY TABLES` and `LOCK TABLES`. Server-level privileges such as `FILE`, `PROCESS`, `SUPER`, `GRANT OPTION` and `SHUTDOWN` should never be assigned to a website’s database user, regardless of what username it runs under. ## Creating a limited MySQL user for Joomla 1. In your hosting control panel, create a new MySQL user with a strong, unique password. Most hosts provide this under a MySQL Databases or Database Users section in cPanel or Plesk. 2. Grant that new user privileges on only the one database Joomla uses, not on every database on the account. 3. Update `configuration.php` in your site’s root folder with the new `$user` and `$password` values. This cannot be changed from inside Joomla’s Global Configuration screen; it has to be edited directly in the file, or via SFTP if your host provides file access. 4. Log in to `https://yoursite.com/administrator` and confirm the site still connects and loads correctly. 5. Once you have confirmed the new user works, delete the old `root`\-based connection from the database server entirely. Do not leave it dormant. 6. If there is any chance the site has been compromised in the past, change the actual MySQL `root` password too, and check for any unexpected additional MySQL users that were not created by you or your host. ## Why the root user swap isn’t one-click We check the configured database username on every snapshot and flag a match against `root`. There is no one-click fix for this, because creating a new database user and migrating the credentials is an infrastructure change that has to happen at the hosting level, so we flag it and point you to the fix rather than attempting it for you. This check pairs with three others in the same family: whether your database prefix is [still the guessable default](https://mysites.guru/tools/database-integrity/default-database-prefix/), whether your database user [can see other databases on the server](https://mysites.guru/tools/database-integrity/database-user-sees-other-databases/), and whether [leftover installer backup tables](https://mysites.guru/tools/database-integrity/leftover-backup-tables/) are sitting in your live database. ## [Your Database User Should Not Be root](https://mysites.guru/free-audit/?check=joomla/databaseintegrity/databaseuser) mySites.guru checks every connected site for this automatically and flags it the moment it appears. These run twice a day on every connected site. [Check your site for free](https://mysites.guru/free-audit/?check=joomla/databaseintegrity/databaseuser) ## Further Reading - [Official MySQL: How to Reset the Root Password](https://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html) - [Official MySQL: Adding User Accounts](https://dev.mysql.com/doc/refman/5.5/en/adding-users.html) ## Frequently Asked Questions Show all How common is it for a Joomla site to connect as root? Rare. Across the sites we audit, roughly 0.1% run with a root database user. Most hosts either block root connections from web applications entirely or never hand out root credentials for anything but server administration, so this is not the risk most sites face. What is actually wrong with using root, if it works fine day to day? Nothing is visibly wrong day to day. The problem only shows up the moment something goes wrong elsewhere, because root can read, write, create and delete every database on the server, not just the one Joomla uses. Any flaw that exposes your database credentials, or lets an attacker run SQL through your site, hands them the whole server's data at once. I've fixed my database user. Do I need to do anything else? Yes. If your site has ever been compromised, or you are not certain, change the password on the new user too, and delete the old root-privileged one rather than leaving it dormant. A credential nobody uses is still a credential that works. [![EU icon: AI MODIFIED](https://mysites.guru/_astro/ai-modified.CaoawZEQ_1In0VX.webp)Written and edited by a human, with AI assistance. Our approach to AI](https://mysites.guru/ai-statement/) ### Article Contents - [How the root database user check works](#how-the-root-database-user-check-works) - [How one SQL injection becomes a whole-server breach](#how-one-sql-injection-becomes-a-whole-server-breach) - [The privileges a database user should actually have](#the-privileges-a-database-user-should-actually-have) - [Creating a limited MySQL user for Joomla](#creating-a-limited-mysql-user-for-joomla) - [Why the root user swap isn’t one-click](#why-the-root-user-swap-isnt-one-click) - [Further Reading](#further-reading) - [Frequently Asked Questions](#faq) - **Published** - 28 August 2026 - **Applies to** - Joomla - **One-click fix** - Manual fix Share [](https://x.com/intent/post?url=https%3A%2F%2Fmysites.guru%2Ftools%2Fdatabase-integrity%2Fdatabase-user-is-root%2F&text=Your%20Database%20User%20Should%20Not%20Be%20root)[](https://bsky.app/intent/compose?text=Your%20Database%20User%20Should%20Not%20Be%20root%20https%3A%2F%2Fmysites.guru%2Ftools%2Fdatabase-integrity%2Fdatabase-user-is-root%2F)[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysites.guru%2Ftools%2Fdatabase-integrity%2Fdatabase-user-is-root%2F) Topics [Database integrity](https://mysites.guru/tools/database-integrity/)Joomla ★★★★★ > "An [essential solution for agencies](https://mysites.guru/pricing/). Best Service!" ![Adi Heutschi](https://mysites.guru/images/reviews/adi-heutschi.webp) Adi Heutschiadiheutschi.ch Webdesign & Hosting [](https://mysites.guru/reviews/) ## More checks in [Database integrity](https://mysites.guru/tools/database-integrity/) - [ ### One Site, One Database User If your Joomla database user can see other databases on the server, one compromised site's credentials can expose every site that shares that hosting account. ](https://mysites.guru/tools/database-integrity/database-user-sees-other-databases/) - [ ### The Default Database Prefix A jos\_ Joomla database prefix isn't a vulnerability by itself. It's a force multiplier for one, and a sign the site started life on a much older Joomla version. ](https://mysites.guru/tools/database-integrity/default-database-prefix/) - [ ### Backup Tables Left In The Database Joomla's installer renames old tables to bak\_ instead of deleting them. They sit in your live database, readable by anything that reaches your data. ](https://mysites.guru/tools/database-integrity/leftover-backup-tables/) ## More from the blog [ ![How to Check Your Joomla Database Security with mySites.guru](https://mysites.guru/_astro/joomla-database-security.Bmo7ySy7_22Qlsd.webp) ### How to Check Your Joomla Database Security with mySites.guru Your Joomla database might be running with the default jos\_ prefix, a root user, or excessive privileges. Here's how to flag each issue and fix it. ](https://mysites.guru/blog/how-to-check-joomla-database-security/) ## See where your own sites stand One free audit of one site · no card · about 2 minutes to connect [Get Your Free Site Audit](https://manage.mysites.guru/en/register) [How the root database user check works](#how-the-root-database-user-check-works) [How one SQL injection becomes a whole-server breach](#how-one-sql-injection-becomes-a-whole-server-breach) [The privileges a database user should actually have](#the-privileges-a-database-user-should-actually-have) [Creating a limited MySQL user for Joomla](#creating-a-limited-mysql-user-for-joomla) [Why the root user swap isn’t one-click](#why-the-root-user-swap-isnt-one-click) [Further Reading](#further-reading) [Frequently Asked Questions](#faq)