DreamHost forced password resets for email and FTP/SFTP users after an incident that began with connectivity problems in its File Manager interface on October 23 and spread to other services. The company blocked access for all users until they completed a reset, described the step as a precaution, and sent recovery instructions in batches over the weekend. As of reporting, the incident was still active and File Manager remained unavailable.
The company serves over 400,000 customers in more than 100 countries and supports at least 1.5 million websites and applications, including 750,000 WordPress installations. Those numbers explain why a forced reset of this kind is a logistical event rather than a support ticket.

The instruction that reveals the threat model

DreamHost told affected account holders to review each email address for forwarding rules and to remove any forwarding destination they did not recognise.
That recommendation is the most informative sentence in the disclosure. A forwarding rule is a persistence mechanism that survives a password reset, needs no malware on the endpoint, and sends copies of inbound mail to an address the attacker controls. If the company is asking customers to look for unrecognised destinations, it is treating mailbox access as something an unauthorised party may have obtained. DreamHost has not said so directly; that remains an inference from its own guidance.
The second recommendation, to change reused passwords elsewhere if the DreamHost password was used on other services, follows the same logic from the credential side.

The structural problem with mailbox resets

DreamHost said it cannot contact individual mailbox or FTP users directly. Account owners must notify their users by phone, text or another channel, because the people whose passwords were reset may be unable to reach their email at all.
This is not a communications failure specific to one provider. A mailbox is the recovery channel for most other accounts. When the mailbox is the thing being reset, the recovery path for reaching its owner runs through the mailbox itself.
For an organisation with mailboxes at a hosting provider, the practical implication is that the account owner needs an out-of-band roster of who uses which mailbox. Without it, the owner is calling people one at a time to tell them their email is locked. With it, the reset is a list and a message on a channel the users can still reach.

What the incident record does not contain

BleepingComputer reported that it contacted DreamHost several times for the number of impacted accounts and whether files or messages were exposed, and had not received an answer at publication. Long-time customers complained about the lack of detail.
That gap matters for downstream decisions. An account owner deciding whether to notify their own customers has to know whether message contents were accessible or only the login credentials. Those are different incident classes with different obligations.
The measured response is to assume the wider case until the narrower one is confirmed, because the remediation cost of the wider case is a password reset that was already forced.

A workable response for hosting customers

Start with the forwarding rules, before anything else. They are the one persistence mechanism the provider explicitly named, and they are readable from the control panel by the account owner without vendor assistance.
Then enumerate the mailboxes the account owns. The list should include role mailboxes, aliases that forward to personal addresses, and mailboxes belonging to contractors who left. A reset campaign that misses a forwarding alias leaves the attacker with a working path.
Then check for mail clients and application passwords. A hosted mailbox often has several credentials: the web login, an IMAP password in a phone, and an application password used by a form or a scanner. Resetting the account password does not necessarily invalidate those, depending on how the provider implements application passwords.
Finally, tell the users on a channel that is not the mailbox. The provider cannot, so the account owner has to.

What to ask the vendor

Two questions are worth putting to any hosting provider after an incident of this shape. Which credentials were reset, and which were not? The answer determines whether the persistence path is closed. And does the reset invalidate sessions and application passwords, or only the primary password? The answer determines what still works for the attacker.
Neither question requires the provider to publish forensic detail. Both are answerable from the systems that performed the reset.

References

[1] BleepingComputer, "DreamHost forces password resets in ongoing "incident"", October 26, 2026. https://www.bleepingcomputer.com/news/security/dreamhost-forces-email-ftp-sftp-password-resets-in-ongoing-incident/