DreamHost’s first days of this incident were short on detail: passwords were being reset as a precaution, the File Manager was down, and no cause was given. On 29 October, the company changed the story itself. In a post titled “October Security Incident”, DreamHost says an unauthorized third party accessed the server running its web-based File Manager, exploited a vulnerability in the third-party software that tool is built on, and reached the FTP and SFTP usernames and passwords of customers who had logged into File Manager before the attack was detected on 23 October. This was not, in DreamHost’s own word, a glitch. The company calls it a deliberate attack, and the admission reframes everything that came before it: the password resets were not just precautionary, they were a response to credentials the attacker could already hold.
What did the attacker actually get?
The confirmed access, according to DreamHost’s 29 October post, has three layers, and the layers matter because they decide who needs to act. First, the attacker accessed the FTP and SFTP usernames and passwords of users who logged into File Manager before the activity was detected on 23 October 2026. File Manager, at files.dreamhost.com, is the browser-based tool customers use to work on the files on their websites, and DreamHost says the attacker exploited a vulnerability in the third-party software it is built on. Second, the attacker also reached certain webmail systems and obtained the login credentials of a limited number of webmail users. DreamHost reset those passwords and ended active sessions the same day. Third, in a small number of cases, DreamHost believes the attacker may have used those credentials to view mailbox contents, and in such cases the company says it is contacting those customers individually. That third layer is the narrowest and the most serious, and it is stated as DreamHost’s belief, not as a confirmed count of mailboxes read.
What the attacker did not get is stated just as plainly, and it limits the damage. Based on its investigation to date, DreamHost says it has found no evidence that the unauthorized third party accessed control panel logins or customer billing details. DreamHost does not store full payment card numbers, because card payments are handled by a third-party payment processor. So, on the evidence DreamHost has published so far, this is a credentials incident, with no evidence of billing-data access. The company has not named the attacker, has not named the exploited vulnerability, and has not given an affected-account count. Its only scope statement is a proportion, not a number: its current analysis indicates the incident affected a fraction of email and FTP/SFTP accounts hosted at DreamHost, well under approximately 10%. That fraction is DreamHost’s characterization, and it cannot be turned into a headcount, because the company has not published the denominator. Anyone quoting a number of affected customers for this incident is inventing it.
Am I affected? Two tests, and one reassurance
DreamHost gives two “you may be affected” tests, and both are worth running, because the second one explains the confusing emails many customers received. You may be affected if you, or an FTP or SFTP user on your account, logged into File Manager between approximately August 2026 and October 23, 2026. If that applies, DreamHost says to treat those usernames and passwords as compromised, and if you use the same or a similar password for any other account or service, to change it there as well. That window covers roughly three months of File Manager logins, which is why the credential advice is so broad. You may also be affected if an email user on your account was signed out and the old password stopped working on or after October 23. That, DreamHost says, was the company itself: it reset the passwords of mailboxes it believed could have been affected while the investigation continued.
The reassurance cuts the other way, and it is the part most coverage missed. DreamHost says its ongoing investigation suggests that not everyone who received that initial email was affected, and fewer customers are known to be affected now than originally suspected. Even if one of the two tests above applies to you, DreamHost says, it does not necessarily mean you were affected. And there is a clean negative test: if a previously-working password on an email or FTP/SFTP account still works and you have not changed it yourself, the investigation to date indicates it was not exposed in this incident, although DreamHost still encourages changing it as an added precaution. If you did not receive an email from DreamHost about this issue, the company says no action is needed at this time, though the precautions below are still worth considering. That combination, a broad treat-as-compromised window plus a narrow known-affected set, is the honest shape of this incident: act on the window, but do not assume the worst about every account.
What should DreamHost customers do now?
The split that matters most is who can act. Only the DreamHost account holder can set new passwords, from inside the account control panel, and individual mailbox or FTP users cannot fix this themselves. DreamHost says it cannot contact individual mailbox or FTP users directly, according to BleepingComputer’s 26 October report, which is why account owners were urged to notify affected users by phone, text, or other means. Account owners set new passwords under “Mail > Manage Email” for mailboxes or “Websites > SFTP Users & Files” for FTP and SFTP users, and a changed password may take up to 15 minutes to take effect. Affected mail, FTP, and SFTP accounts are still active and functional, DreamHost says, but their users will need new passwords before they can sign in again. Websites and email remained available throughout the incident, inboxes continue to receive email whether or not passwords have been reset, and files remain in the FTP and SFTP accounts.
Then come the four checks DreamHost itself recommends. Use strong, unique passwords for every user on the account, and update any email, FTP, or SFTP clients that have the old passwords saved, or those clients will keep failing and tempting a revert to the old password. Look over website files for any changes you do not recognize. Check webmail settings, especially forwarding rules and filters, for anything you did not set up yourself, because a forwarding rule added by someone else could keep copying mail even after a password change, a possible risk, and the reason DreamHost asks customers to check for rules they did not set up. That forwarding check is the one this article emphasizes most: a new password does not remove a forwarding rule someone else added. Finally, the phishing warning, which DreamHost repeats across its post and its status page: DreamHost will never email you asking for your password, its incident emails never ask you to sign in through a link, and account passwords can only be changed by the account holder from the control panel at panel.dreamhost.com, typed directly into the browser, never reached through a link in an email. The days after a disclosed incident are when fake reset emails look most convincing, because real ones have just arrived.
How did this unfold, and what is DreamHost doing?
The timeline, reconstructed from DreamHost’s status updates as reported by Help Net Security, is the original reconstruction for this article. The first status entry came on 23 October at 2:20 PM Pacific, for File Manager connectivity issues. By that evening the File Manager was offline, some webmail users were signed out, and password resets had begun. The resets were complete on 24 October at 10:37 AM Pacific, all affected account owners had been emailed by 25 October at 9:32 PM Pacific, and File Manager returned on 26 October at 3:35 PM Pacific, with DreamHost monitoring the fix. From first entry to File Manager’s return is roughly 73 hours, about three days of File Manager disruption, and from the 23 October discovery to the 29 October admission is six days. The status page today shows File Manager, Email Hosting, and Webmail all Operational, verified on 31 October. What DreamHost says it has done since: the affected File Manager server has been taken out of service and preserved for forensic investigation, File Manager has been rebuilt and relaunched with additional security precautions and enhanced monitoring, internal credentials that may have been exposed have been rotated, the vulnerability identified as the cause has been addressed, other customer-facing tools are under review for similar vulnerabilities, and outside security and forensics experts have been retained while the investigation continues. Regulators are being notified as required by law, and formal notices will follow in the coming days under the laws of the countries where affected users are located.
Two clarifications close the gaps other coverage left open. First, DreamHost says this incident was not related to recent PHP server updates: its PHP servers were patched within hours of the patches’ availability, and its web application firewall blocked tens of thousands of intrusion attempts in the days leading up to that release. That separates this attack from the separate 21 October PHP-vulnerability status post, and from the separate 17 October Panel Login disruption, neither of which is this incident. Second, the company’s silence in the first days was not the whole story: BleepingComputer reported on 26 October that it had contacted DreamHost multiple times about the cause, the number of impacted accounts, and whether files or messages were exposed, and had not heard back as of publication. The 29 October post answers the first and third questions, cause as a File Manager software vulnerability and exposure as FTP credentials plus limited webmail credentials, and leaves the second, the count, as a proportion only. Until DreamHost publishes a number, or regulators’ notices surface one, “well under approximately 10% of email and FTP/SFTP accounts” is the only scope figure this story can honestly carry, and the customers who should act are the ones in the August-to-October File Manager window, whether or not they ever got the email.
