SURIQ
Resetting a password ends an intruder's next login. It does nothing about what they did with the logins they already had. That is the gap DreamHost customers now have to close. According to the company's breach notice, an attacker sat inside the server behind its web-based File Manager from August until October 23, 2026, collecting the FTP and SFTP usernames and passwords of everyone who signed in there. Those credentials open a website's files directly. If yours was in that set, the real question is what was written to your site while the attacker held them.
How did the DreamHost breach happen?
An unauthorized party exploited a vulnerability in the software running DreamHost's File Manager at files.dreamhost.com, according to the notice reported by BleepingComputer on November 4. DreamHost has not named the flaw. The attacker took the logins entered there and may also have reached webmail session data for a limited number of users.
FTP (File Transfer Protocol) and its encrypted counterpart SFTP are how most shared-hosting customers upload and edit their sites. DreamHost told TechCrunch that the affected share is well under 10% of customers, out of roughly 400,000 paying ones, and declined to be more precise. BleepingComputer said repeated questions about the count went unanswered.
The two outlets frame the webmail exposure slightly differently. TechCrunch describes stolen session tokens, the values that keep a user logged in. BleepingComputer describes session information, including credentials, for a limited group. Either way, a valid session is a working key to the mailbox until it is killed.
DreamHost says it found no evidence the attacker reached control panel logins or billing data, which an outside provider handles. The company says it blocked the access, fixed the vulnerability, ended active sessions and invalidated passwords for affected users, and is offering a year of Equifax credit monitoring. It also told TechCrunch the incident is unrelated to recently reported PHP vulnerabilities, and it has filed a breach notice with California's attorney general.
The dates matter more than the fix. Access began in August, discovery came on October 23, and the confirmed breach was reported on November 4. DreamHost has not explained the detection gap, citing the ongoing investigation. Any change made to a customer site in those weeks predates every reset.
Why a web file manager collects passwords for an attacker
A browser-based file manager that connects to FTP on your behalf has to receive your password to do it. That puts one server in the path of every customer who would rather click than run an FTP client. Take over that server and there is no phishing to do: the logins arrive by themselves, from the exact people actively maintaining their sites. This is our reading of how such front ends work, not a detail DreamHost has published, but it fits the way the stolen set is defined, as people who logged in during the window rather than every account.
Anyone running hosting infrastructure should take the transferable lesson. Shared web tooling such as file managers, webmail and panel add-ons sits in front of many tenants at once, so one bug there is worth more to an attacker than any single customer site. Those front ends deserve the same logging and patch priority as the control panel. The cPGuard update hijack showed the same economics from another angle: one trusted shared component, thousands of servers reached.
What survives a forced password reset
Invalidating passwords and sessions stops reuse of what was stolen. It does not undo what was done with it. We made the same argument about FortiBleed session theft, and it applies here with more force because the stolen logins grant write access to live websites.
-
Site files. Anyone holding valid FTP or SFTP credentials during the window could upload or edit files. A PHP web shell, a backdoor script that answers an attacker's requests, keeps working after the password that planted it is gone. Our coverage of exploited Joomla page builders made the same point: a fix does not evict what is already on disk.
-
Mail rules. A forwarding rule or filter created through a hijacked webmail session runs on the server and outlives the session. DreamHost tells customers to review them.
-
Accounts reachable through the mailbox. This one is easy to miss. Whoever can read an inbox can request password resets for services registered to that address: the domain registrar, a payment processor, a WordPress admin login. Check those accounts for reset emails or logins you did not start.
-
Reused passwords. If the old FTP password guards anything else, change it there too, as DreamHost advises.
Which site files changed between August and October 23?
If your DreamHost user has shell access, start with modification times inside the window, then search PHP files for common obfuscation patterns. Treat a clean result with care: an attacker with write access can reset a file's timestamp, so the stronger test is a diff against a copy of the site taken before August.
find ~ -type f \( -name '*.php' -o -name '.htaccess' -o -name '*.js' \) -newermt 2026-08-01 ! -newermt 2026-10-24 -ls grep -rlE 'eval\(base64_decode|gzinflate\(base64_decode|assert\(\$_(POST|GET|REQUEST)' ~ --include='*.php' cat ~/.ssh/authorized_keys crontab -l
The last two lines look for persistence that a password change never touches: an SSH key added to the account, or a scheduled job that quietly re-downloads a shell. Any hit is a lead, not a verdict, since plenty of legitimate plugins ship encoded code. Backups made during the window can carry the same changes, so if you find tampering, restore from one dated before August.
Diff the site against a pre-August backup today
DreamHost has not published indicators of compromise, the exploited flaw, or an account count. Until it does, a customer's own files are the only evidence available, and a dwell time measured in weeks means write access should be assumed used until a diff says otherwise. Ask DreamHost support whether your account was in the affected set, pull the oldest clean backup you have, and compare. This is the case file integrity monitoring exists for: a record of what changed and when, kept somewhere the intruder could not edit.