DreamHost forces password resets across all mail and FTP accounts amid ongoing incident

What happened

DreamHost has forced a password reset on every mailbox and FTP/SFTP account it hosts following what the company describes as an ongoing security incident. According to a write-up on dev.to, the trouble started on October 23 with connectivity faults in DreamHost's File Manager and then spread to other services. DreamHost subsequently blocked access for all affected users until they completed a reset, called the move a precaution, and rolled out recovery instructions in stages over the weekend. At the time of the dev.to post, the incident was still active and File Manager remained offline.

The scale of the company explains the disruption. Per the dev.to write-up, DreamHost serves more than 400,000 customers in over 100 countries and hosts at least 1.5 million websites and applications, including roughly 750,000 WordPress installations.

The advice that points at the threat model

Alongside the reset, DreamHost told account holders to review each email address for forwarding rules and delete any forwarding destination they did not recognise, and to change the DreamHost password anywhere it had been reused on other services.

The dev.to analysis focuses on the forwarding-rule instruction. A forwarding rule keeps working after a password change, because inbound mail continues to be copied to whatever destination the rule names, so it is a way for an intruder to hold on to a mailbox even after credentials are rotated. In the author's reading, the fact that DreamHost is telling customers to hunt for unfamiliar destinations implies the company considers unauthorised mailbox access a realistic possibility. DreamHost has not said so explicitly.

Why owners, not DreamHost, have to spread the word

DreamHost said it cannot reach individual mailbox or FTP users directly. Account owners are expected to notify their own users by phone, text or another channel, because people locked out of their mail cannot be emailed about it.

The dev.to post argues this is a structural problem rather than a failure unique to one provider: most online accounts treat the mailbox as their recovery channel, so when the mailbox itself is the thing being reset, the usual route for reaching its owner runs through the very thing that is locked. The suggested mitigation for organisations is to keep an out-of-band list of who uses which mailbox, turning a reset into a message sent on a channel that still works.

What is still unknown

BleepingComputer reported that it asked DreamHost repeatedly how many accounts were affected and whether any files or messages were actually exposed, and had received no answer by its publication on October 26, 2026. Long-standing customers have reportedly criticised the shortage of detail.

That gap affects downstream decisions. Whether message contents were accessible, or only login credentials, defines two different classes of incident with different notification duties for the organisations that own the mailboxes. The dev.to author's suggested default is to assume the broader case until the provider confirms the narrower one, since the remediation for the broader case is a password reset that has already been forced.

A checklist for affected customers

The dev.to post sets out an order of operations. Check forwarding rules first, since the control panel shows them without vendor assistance. Then list every mailbox the account owns, including role addresses, aliases that pass mail onward, and mailboxes belonging to contractors who have since left. Then verify mail-client and application credentials: a hosted mailbox often has several, such as an IMAP password saved on a phone or an app password used by a web form or a scanner, and rotating the primary password does not necessarily invalidate them. Finally, contact users on a channel other than the mailbox itself.

Two questions are worth putting to DreamHost or any host in this situation, the post adds: exactly which credentials the reset covered and which it did not, and whether the reset invalidated sessions and application passwords or only the main login. Neither requires the provider to publish forensic detail.

Why it matters

A provider-wide forced reset at a host serving 1.5 million sites is rare and inherently disruptive, and this one hit the recovery mechanism most people rely on. The strongest signal in the disclosure, the instruction to look for unknown forwarding destinations, suggests DreamHost is treating mailbox compromise as plausible, and nobody outside the company yet knows whether mail or file contents were exposed. For anyone running hosted mail, the incident is a working lesson in out-of-band planning: keep a roster of mailbox users, know which secondary credentials exist, and assume the vendor cannot reach the people affected.