The DreamHost breach exposed FTP and SFTP usernames and passwords, plus login details for some webmail users, after an attacker got into the server behind DreamHost’s web-based File Manager. DreamHost says the access ran from about August 2026 until it found the intrusion on October 23, 2026. It forced password resets for affected users and says it saw no sign that control panel logins or billing details were touched.
If you run WordPress sites on DreamHost, for your own organization or for clients, this post covers what DreamHost has said, what press coverage adds, and a checklist for each site. Facts are as of the afternoon of November 8, 2026. For a wider look at what to expect from a host, see our guide on how to choose a managed WordPress host.
The short version: if anyone on your account used DreamHost’s File Manager between August and October 23, treat those SFTP passwords as stolen, because DreamHost says to. Change every website user and mail password, then check each WordPress site for new admin users and changed files. If an SFTP login could read wp-config.php, change the database password and the WordPress salts too. Turn on multifactor authentication for the DreamHost panel.
How the DreamHost breach happened
DreamHost’s October Security Incident announcement, dated October 29, says it found the intrusion on the afternoon of Friday, October 23. An unauthorized third party had accessed the server running File Manager at files.dreamhost.com. DreamHost says File Manager is "built on third-party software," and the attacker exploited a vulnerability in that software. The announcement does not name the software.
DreamHost emailed account owners that Friday evening and through the weekend about password resets for email and FTP/SFTP users. The announcement says the incident "affected a fraction of email and FTP/SFTP accounts hosted at DreamHost, well under approximately 10%."
A breach notice letter DreamHost filed with the California Attorney General gives the time frame. It says the access happened between August 2026 and October 23, 2026, and calls it a deliberate attack. The letter’s date field is blank in the posted copy.
DreamHost also says the incident "was not related to recent PHP server updates." That matters if you saw site problems after a PHP version change and wondered if the two were linked.
What the DreamHost breach exposed
DreamHost lists three kinds of exposure in its announcement and its notice letter:
| What | Who it affects | What DreamHost says |
|---|---|---|
| FTP/SFTP usernames and passwords | Users who logged in to File Manager from about August to October 23 | “Please treat those usernames and passwords as compromised.” |
| Webmail login and session details | A limited number of webmail users | Session information “including session credentials” may have been exposed |
| Mailbox contents and files | A small number of cases | The notice letter says email contents and files on the FTP/SFTP server “may have also been accessed” |
DreamHost says it found no evidence the attacker accessed control panel logins or customer billing details. It also says it does not store full payment card numbers.
For WordPress owners, the first row is the one to act on. An SFTP login can read and change every file the user owns. On a typical WordPress install that includes wp-config.php, which holds the database password and the site’s security keys and salts.
What DreamHost did in response
According to DreamHost’s announcement, it:
- Took File Manager offline and preserved the affected server for forensics.
- Reset passwords for affected users and ended their active sessions.
- Fixed the vulnerability and rebuilt File Manager with added security and monitoring.
- Rotated internal credentials that may have been exposed.
- Started reviewing other customer-facing tools for similar flaws.
- Brought in outside security and forensics experts and began notifying regulators.
The notice letter adds an offer of one year of Equifax credit monitoring for people who receive it. On November 8, the DreamHost status page listed the File Manager interface as operational.
What press coverage adds
BleepingComputer covered the DreamHost breach twice. On October 26 it reported that DreamHost had blocked access for affected users until new passwords were set. It also reported that mailbox and FTP users could be locked out until the account owner gave them new credentials, because DreamHost cannot contact those users directly.
On November 4, BleepingComputer reported the breach notice filed in California. It said DreamHost did not answer its questions about how many customers were affected. We have not seen a count from DreamHost beyond "well under approximately 10%."
Step 1: Change passwords after the DreamHost breach
Work through these steps for each site on the account. Only the DreamHost account holder can set new passwords. DreamHost’s announcement says passwords can only be set "from inside the DreamHost account control panel."
Change SFTP, shell and mail passwords
Change every website user’s password, not only the ones DreamHost reset. DreamHost’s help article on changing website user passwords walks through it. Go to SFTP Users & Files, click Login info on the user’s row, then Change password. The help center says to allow up to five minutes before logging in.
Do the same for mail users. Then update saved passwords in mail apps, SFTP clients and deploy tools. DreamHost’s passwords overview caps passwords at 31 characters and does not allow quote marks.
If any of these passwords were reused elsewhere, change them there too. Our post on password security basics covers using a password manager to keep them unique.
Check webmail rules and filters
DreamHost asks every mail user to check forwarding rules and filters for settings they did not create. An attacker with mailbox access can add a quiet forward that keeps copying mail after the password changes. Delete any forward you do not recognize.
Step 2: Rotate the database password and WordPress salts
If an SFTP user could read wp-config.php, assume the attacker has the database password. Change the MySQL user’s password in the DreamHost panel, then update DB_PASSWORD in wp-config.php to match.
Next, replace the security keys and salts. WordPress’s developer reference for wp_salt points to an official generator at api.wordpress.org/secret-key/1.1/salt/. With WP-CLI, wp config shuffle-salts does the same job. New salts make existing login cookies stop working, so every logged-in user, including anyone holding a stolen cookie, must sign in again.
Then reset passwords for every administrator account. If you plan to move secrets out of wp-config.php altogether, our env-var secrets migration checklist covers the steps.
Step 3: Look for new admin users and changed files
DreamHost tells customers to look over website files for changes they do not recognize. Its notice letter says files on the FTP/SFTP server may have been accessed. On WordPress, check these places:
- Admin users. Run
wp user list --role=administrator, or check Users in the dashboard. Remove any account you did not create. - Recently changed PHP files. From the site root,
find . -name "*.php" -mtime -110lists PHP files changed in roughly the past 110 days, which covers August onward. - Uploads. PHP files in
wp-content/uploads/are a common sign of a backdoor. - Must-use plugins. Check
wp-content/mu-plugins/for files nobody added. - Core files.
wp core verify-checksumscompares core files against WordPress.org.
These are standard WordPress and Linux checks, not steps from DreamHost. If you find changes dated inside the DreamHost breach window, restore from a backup taken before August, then update everything. Our recent posts on the cPGuard compromised update and the WordPress 7.1.4 security release cover the same kind of cleanup and patching.
Step 4: Move from passwords to SFTP with SSH keys
DreamHost’s SFTP help article says port 22 "is the only value you should use since this uses the secure SFTP protocol." If any tool still connects over plain FTP, switch it to SFTP.
A stronger step is key-based login. DreamHost’s guide to passwordless login on Mac and Linux recommends an ed25519 key. It requires the user to be a shell user. A key on your laptop cannot be stolen from a server-side tool the way a typed password can.
Step 5: Turn on multifactor authentication for the panel
DreamHost’s multifactor authentication overview covers panel logins with an authenticator app such as Google Authenticator, or a YubiKey. The panel is where every other password gets reset. The DreamHost breach did not reach panel logins, and MFA helps keep it that way. See our explainers on multifactor authentication and authenticator apps.
The same overview says "DreamHost email service does not support Multifactor Authentication (MFA)." Mail accounts rely on the password alone, which makes strong, unique mail passwords more important.
What agencies should tell clients
Agencies often hold SFTP users on client-owned DreamHost accounts. After the DreamHost breach, only the account holder can set new passwords, so the client may need to act first. Send a short note with three items: change all website and mail passwords in the panel, turn on panel multifactor authentication, and send you the new SFTP details through a password manager share, not email.
Keep a log of what you changed and when. If a client’s site handles member or donor data, the cleanup notes feed into their data breach response plan.
What we do not know yet
Several questions about the DreamHost breach remain open as of November 8:
- Which third-party software. DreamHost has not named the File Manager software or the vulnerability.
- How many accounts. DreamHost says "well under approximately 10%" and has not given a number.
- Whether files were changed. DreamHost says files "may have also been accessed" and tells customers to check for changes. It has not said whether it found any changes.
DreamHost says it will notify users of significant developments. We will update this post if it adds details about the DreamHost breach.
Frequently Asked Questions
What did the DreamHost breach expose?
FTP/SFTP usernames and passwords for people who logged in to File Manager from about August to October 23, 2026, and login or session details for a limited number of webmail users. DreamHost says email contents and files may also have been accessed in some cases.
Were DreamHost control panel passwords exposed?
DreamHost says it found no evidence the attacker accessed control panel logins or customer billing details. Turning on panel multifactor authentication is still a good step.
I never used File Manager. Am I affected?
The FTP/SFTP exposure covers users who logged in to File Manager during the window. Webmail exposure is separate. If DreamHost reset your passwords or emailed you, treat the account as affected. Changing passwords is cheap either way.
Who can reset passwords on a DreamHost account?
Only the account holder, from inside the DreamHost control panel, according to DreamHost. Agencies and mail users need the owner to set new credentials.
Do I need to change my WordPress salts?
If an SFTP user could read wp-config.php, yes. New salts end every existing login session. Change the database password and admin passwords at the same time.
How do I check a WordPress site for changes after the DreamHost breach?
List admin users, look for recently changed PHP files, check wp-content/uploads and mu-plugins for unexpected PHP, and run wp core verify-checksums. Restore from a backup taken before August if you find changes.
Does DreamHost support multifactor authentication?
Yes, for panel logins, using an authenticator app or a YubiKey. DreamHost says its email service does not support multifactor authentication.
Should I stop using FTP?
Yes. DreamHost’s own SFTP guide says to use port 22 and the SFTP protocol. For the strongest setup, use a shell user with an SSH key instead of a password.
Was the breach caused by DreamHost’s PHP updates?
No. DreamHost says the incident was not related to recent PHP server updates.
