DreamHost has emailed customers asking them to change the password of every user on their accounts after an issue affecting its File Manager and webmail. Treat it as a full credential rotation: panel login, mailboxes, SFTP and shell users, database users, and WordPress admins. Then check each site for new admin accounts, changed files and email forwarding rules.
If you got the email on a busy afternoon, the natural move is to change your panel password, feel a little better, and get back to work. That covers one user out of many. Most DreamHost accounts we've seen have a panel login, a few mailboxes, at least one SFTP user, a database user per WordPress site, and a handful of WordPress admins. The notice asked you to change all of them, and there's a sensible order for doing it.
What did the DreamHost security alert say?
The alert told DreamHost customers to update the password for every user on their accounts. DreamHost tied it to an issue affecting its File Manager and webmail. That is the confirmed part. Anything beyond it, such as how many accounts were touched or what someone could have done, is a detail to get from DreamHost directly.
We're sticking to what DreamHost has confirmed. If DreamHost has posted more on its status page or in a follow-up email since, that newer notice wins over anything written here.
The two services it named matter because of what they reach. File Manager lets you open and edit your website files in a browser, including wp-config.php, which holds your database password in plain text. Webmail is where your password reset links, invoices, client messages and plugin license emails land. Between them, they touch your site files and your inbox.
What a reset notice like this does not tell you:
- Whether your specific account was one that someone accessed
- Whether any files on your sites were changed
- Whether anyone read or forwarded messages in your mailboxes
Those gaps are normal for a preventive notice. It tells you to cut off any login that might be known to someone else. It can't tell you what happened inside your account before you acted, so that part is on you.
If you've already had trouble getting answers from DreamHost, as plenty of owners described in our post on DreamHost fees climbing while support stopped answering, plan to do this work yourself instead of waiting on a ticket.
Which passwords should you change after the DreamHost alert?
Change every credential DreamHost controls, plus the ones stored where File Manager or webmail could reach. That means the panel login, every mailbox, every SFTP or shell user, every database user, and every WordPress administrator. Work from the top down so a reset link never lands in an inbox someone else can still read.
Here's the order we use, and why each one is on the list.
| Order | Credential | Why it's on the list | What to update after |
|---|---|---|---|
| 1 | DreamHost panel login | Controls every other user and every reset | Turn on multifactor login |
| 2 | Every mailbox password | Webmail was named in the alert; reset links land here | Phones, laptops, apps that send mail |
| 3 | SFTP and shell users | These users own your site files | FTP clients, deploy tools, backup plugins |
| 4 | MySQL database users | The password sits in plain text in wp-config.php | The DB_PASSWORD line in wp-config.php |
| 5 | WordPress admin accounts | Admins can install plugins and create users | Your password manager |
| 6 | WordPress salts | Logs out every active session at once | Run wp config shuffle-salts |
| 7 | API keys in files or old emails | Stripe, SMTP and backup keys often live in wp-config or inbox history | Each provider's dashboard |
Mailboxes come before WordPress for a plain reason. When you reset a WordPress password, WordPress sends an email. If someone can still read that inbox, you've handed them the new password.
The database step needs a little care. Change the password in the DreamHost panel, then edit DB_PASSWORD in wp-config.php right away. In the gap between the two, the site shows "Error establishing a database connection," so do it in a quiet hour. If a site won't come back after the change, our 20-minute triage order for a site that suddenly won't load walks through DNS, SSL and fatal errors before you assume the worst.
If you used any of these passwords anywhere else, change them there too. According to a Google and Harris Poll survey, 65% of people reuse the same password across multiple or all of their accounts (2019). A mailbox password that also unlocks your bank or your Google account turns one host issue into several.
One more thing while you're in the panel. If several sites share one SFTP user, one password opens all of them. Give each site its own user now, while you're resetting everything anyway.
What if someone got in before you reset the passwords?
Then new passwords stop the next login and leave whatever was already placed. A backdoor is a small file that lets someone run code on your site without logging in at all. It keeps working after every password changes, which is why the second half of this job is checking the sites themselves.
We saw this pattern up close with Tamer Designs, an agency that manages more than 340 WordPress sites for its clients. Their trouble didn't start with a host alert, but the shape of it matches what a DreamHost customer should worry about this week.
They kept cleaning hacked client sites. The sites would look fine. Then, days later, the hacks came back. Every cleanup cost time, and every return trip put them in front of a client explaining why the same site was broken again.
When TopSyde Sentinel scanned the fleet on the server side, it found 63 backdoors spread across those 340+ sites. Those leftover entry points explain how the hacks kept returning after each cleanup. Once they were removed, the hacks stopped for good. We wrote up the general version of this loop in why a WordPress site gets hacked again a week after cleanup.
The lesson for you is narrower than their story. Nothing DreamHost has confirmed says files on your sites were changed. But if anyone did have file access before your reset, a fresh password leaves their file in place, and the only way to know is to look.
How to check a WordPress site for unauthorized changes
Look in five places: the admin user list, recently changed PHP files, PHP files inside the uploads folder, core file checksums, and scheduled tasks. Over SSH with WP-CLI it takes about 10-20 minutes per site. Without SSH, a security plugin scan plus a manual look at users and plugins covers most of it.
Run these from the WordPress folder of each site.
1. List every administrator. Look for names you don't recognize and registration dates from the last few weeks.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
2. Find PHP files changed recently. This shows anything modified in the last 14 days. Attackers can fake file dates, so treat this as a starting point.
find . -name "*.php" -mtime -14 -print
3. Look for PHP inside uploads. The uploads folder should hold images and PDFs. A PHP file in there is almost always a problem. Check wp-content/mu-plugins too, since files there load on every page and don't show in the normal plugin list.
find wp-content/uploads -name "*.php"
ls -la wp-content/mu-plugins
4. Compare core and plugin files to the originals. These commands check your files against the official copies on WordPress.org. Premium plugins will show as unverifiable, which is expected.
wp core verify-checksums
wp plugin verify-checksums --all
5. Check scheduled tasks and key settings. Look for cron events you don't recognize and make sure the site address hasn't been swapped.
wp cron event list
wp option get siteurl
wp option get home
Then open .htaccess and the top and bottom of wp-config.php by hand. Extra lines of scrambled code or redirects you didn't write are a red flag. Outside the server, check Google Search Console under Users and permissions for any owner you didn't add.
If you find something, don't delete files one at a time and hope. Follow a full process, like the one in our checklist for cleaning a hacked WordPress site. And if DreamHost later sends you a malware warning with a cleanup fee attached, you can verify a host's infection notice in about 15 minutes before paying anyone.
How to check webmail for forwarding rules and filters
Open each mailbox's settings and review filters, forwarding and auto-replies. A rule that copies mail to an outside address, or deletes messages containing words like "password" or "invoice," is a common way to keep reading an inbox after the password changes. Delete anything you didn't set up yourself.
Check forwarding in two places: inside webmail settings and in the DreamHost panel's mail settings. They're separate, and a forward set in one won't show in the other.
Next, search each inbox for old emails that contain secrets. Try "password," "API key," "login," "credentials" and the names of services you use, like Stripe or your SMTP provider. Anything a developer sent you in plain text over the years should be rotated, because webmail was one of the two services named in the alert.
This is also a fair moment to ask whether your business email belongs on your web host at all. We laid out the tradeoffs in why a host's free mailboxes aren't a business email plan. Moving mail to a dedicated provider means a future web host incident doesn't touch your inbox.
How isolated hosting limits damage from a host-level incident
Isolation decides how far one leaked credential reaches. When each site runs in its own environment with its own users, a password for one site opens one site. Monitoring decides how fast you hear about trouble. Together they shrink a provider incident from an every-site audit to a short list of checks.
No host can promise a provider-level incident will never happen, us included. What a host can control is the blast radius and the response time.
At TopSyde, each site runs in its own isolated environment, so one site's files and database users can't reach another's. TopSyde Sentinel scans files on the server for malware and backdoors, the same engine that found the 63 backdoors in the Tamer Designs fleet. Monitoring runs 24/7. Per our service level agreement, a site-down ticket is answered within 15 minutes, 24/7, and other tickets get a reply in under 2 hours during business hours. Two-factor login for every editor is one switch in the portal, as covered in our post on two-factor login included with hosting.
The network side matters too. Firewall rules and virtual patching can block known attacks before you've had time to patch, and we explained how that works in how a managed host handles a WordPress zero-day. Plans start at $89/mo per site; the full breakdown is on our pricing page.
A checklist for the next hosting security notice
This DreamHost alert won't be the last notice like it from some host you use. Keep this list somewhere you'll find it next time.
- Confirm the notice is real. Type the host's address into your browser yourself instead of clicking the email link. Phishing emails often copy real alerts right after an incident.
- Rotate from the top down. Panel, mailboxes, SFTP and shell users, database users, WordPress admins, salts, then API keys.
- Check every site on the account. Staging copies and old installs you forgot about count, since they share the same server and often the same users.
- Check every mailbox. Filters, forwards, auto-replies and old emails holding passwords or keys.
- Write down what you did and when. Note the date, which passwords changed, and what you found. If something odd shows up a month later, you'll know whether it predates the reset.
- Fix the setup that made this a big job. One SFTP user per site, a password manager, and multifactor login on every account that offers it.
If you manage sites for clients, send them a short note once you're done: what DreamHost said, what you rotated, and what you checked. Clients take a host incident much better when they hear about it from you first.
Frequently Asked Questions
Was my DreamHost account hacked if I got the security email?
Getting the notice means DreamHost asked you to reset passwords after an issue affecting File Manager and webmail. The notice by itself doesn't confirm that anyone accessed your account. Work through the site and mailbox checks above, and ask DreamHost directly if you need details about your specific account.
Do I need to change my WordPress passwords after the DreamHost alert?
Yes. File Manager can open wp-config.php, which holds your database password, and webmail receives WordPress password reset links. Change your mailbox passwords first, then your WordPress admin passwords, then run wp config shuffle-salts to log out every active session.
How do I know if a backdoor was added to my WordPress site?
Look for PHP files in the uploads folder, core or plugin files that fail checksum checks, admin users you don't recognize, and cron events you didn't create. A server-side scan catches files that some plugin scanners miss, which we explain in our post on what free WordPress malware scanners can't see. If you find one, clean the whole site rather than deleting a single file.
Should I move off DreamHost after this incident?
Finish the password rotation and site checks first, since moving a site with a backdoor carries the backdoor along. If this incident is one in a pattern of slow support or rising prices, compare hosts on site isolation, monitoring and response times. You can see how TopSyde handles those, starting at $89/mo per site, in our published case studies.
DevOps & Security Lead
12+ years DevOps, Linux & cloud infrastructure certified
Marcus leads infrastructure and security at TopSyde, managing the server fleet and AI monitoring systems that keep client sites fast and protected. Former sysadmin turned WordPress hosting specialist.
