DreamHost says it reset email and FTP/SFTP passwords as a precaution; nine status updates in 55 hours name no cause

Nine updates, 55 hours, and no cause

DreamHost's own status page, read at 20:30 GMT on Monday 26 October 2026, carries nine updates on one incident. The first is dated 2:20PM PDT on Friday 23 October (21:20 GMT) and the latest 9:32PM PDT on Sunday 25 October (04:32 GMT on Monday). That is 55.2 hours from first to latest (derived). When the page was read, about 71 hours had passed since the first post and about 16 hours since the latest (derived). The page still showed an Active Incident, status "Service Disruption".

In those nine updates the words breach, compromise, attack, unauthorised, exposed, stolen and regulator appear nowhere (counted by searching the saved page text). The word cause appears once, in the first post, as something the Operations team is "working to identify". DreamHost does say it is resetting passwords for email and FTP/SFTP users, and it calls that a precaution.

That does not establish a breach, and it does not establish that there was none. A reset of two credential types is what an operator would do if it suspected those credentials were exposed, and it is also what an operator might do to be safe. The status page does not say which. This briefing reports what DreamHost has written, what it has left out, and what a customer should do while the gap stays open. It does not assume an attack.

DreamHost is a US web host and registrar that sells hosting, email and domains, so its status page is the company's own account of an incident in its own product, and it has a commercial interest in how that account reads. That is the publisher's interest, and it is stated once here. The page was read four times on 26 October, at 20:30, 20:32, 20:39 and 20:40 GMT, and the saved page was byte for byte identical across the curl readings. A CyberInsider report of the same day, read with an identified user agent as its robots.txt allows, was read as a secondary source; it agrees that the latest update was 9:32PM PDT on 25 October. A community thread was read for colour only. Where either differs from DreamHost's page, this article follows the page and says so.

Zoom

What DreamHost's page states, and what it does not

The table sets each question a customer would ask against what the status page says. "Not stated" means the nine updates and the component list, as read, contain nothing on the point. It does not mean DreamHost does not know.

The emailed notice to account owners is not on the status page, and this briefing did not read it. Anything it says beyond the status updates, including any advice on mailbox forwarding rules, is outside this record. Where this article gives such advice in the checklist, it is marked derived and comes from general practice, not from DreamHost.

The clock: three hours to a reset, 34.9 hours to the last email

Every figure below is derived from the time stamps DreamHost prints, which are in PDT. GMT is PDT plus 7 hours on these dates.

Zoom

Three hours after the first post, update 2 already says some email account passwords are being reset. FTP/SFTP joins the reset in update 4, 7.9 hours after the first post. The page says the reset for affected users is complete in update 6, 20.3 hours after the first post, at 10:37AM PDT on Saturday.

The instructions to customers changed in the middle. Update 4 (10:13PM PDT Friday) and update 5 tell owners to wait for DreamHost's email, and say changes made before the reset finishes "will be overwritten". Update 6, 12.4 hours after update 4, says there is no need to wait. An owner who followed the first instruction waited at least 12.4 hours; an owner who did not may have changed passwords that were then overwritten, which is the page's own warning.

The emails are the slow part. Update 6 says the reset is complete and the instruction emails are going out in batches. Update 7 (6:09PM PDT Saturday) says they have begun going out. Update 9 (9:32PM PDT Sunday) says all impacted account holders have been emailed. That is 34.9 hours between update 6, which says the reset is complete, and update 9, which says all impacted account holders have been emailed (derived). A customer in a community thread says one account received the email "over 48 hours after the incident started" and another about seven hours later. That is a single unverified report, but it fits a batched send.

"Operational", "precaution", "incident": three labels doing the work of an answer

The status board marks 3 of its 20 components as Service Disruption: File Manager Interface, Email Hosting and Webmail Interface (counted from the screenshot, derived). The other 17 show Operational, including Web Hosting, DreamPress Hosting, Domain Registrations and Database Hosting.

Zoom

Look for the credential the reset names. FTP/SFTP is how many site owners push files to a hosting account, and it is the second credential type DreamHost resets. It has no line of its own on the component list. A reader who sees Web Hosting marked Operational could believe nothing about site access has changed, while DreamHost's own updates say FTP/SFTP users cannot sign in until their owner sets a new password. That is an inference from the page layout, not a claim DreamHost makes, and it is worth checking for your own deployments: a pipeline that uploads by SFTP with the old password will fail while Web Hosting still reads Operational.

"Precaution" is the second label. It is true that a reset is a control, and a reasonable one. What the word cannot do is tell a customer whether the thing guarded against has happened. The reset covers email and FTP/SFTP credentials only; the page does not say website admin logins, database passwords or panel passwords were reset. That narrows what DreamHost judged at risk (inference), but it says nothing about whether anything was taken.

"Incident" is the third. DreamHost uses the word for everything from a File Manager fault to a forced password reset. The page does not tell a customer whether to treat it as an outage, a security event, or both.

Scale cannot rescue the missing number. DreamHost's company page says over 400,000 customers in more than 100 countries, over 1.5 million websites and 750,000 WordPress installations, which is about 3.75 sites per customer (derived). None of that is the number of accounts reset, and the status page gives no count. A reader should not scale the incident up or down from the company's size.

The lockout: only the account owner can restore a mailbox or an FTP login

DreamHost's latest update says the affected mail and FTP/SFTP users "will be unable to log in until the owner of their DreamHost account resets their passwords and shares the new credentials with them". Update 8 adds that an email or FTP user should contact their account owner, who can set a new password. The diagram follows the sequence from DreamHost's updates and marks the one step that is derived.

Zoom

Step 5 is the one a business should plan for. DreamHost tells an email or FTP user to contact their account owner. The status page does not say how a user who cannot read email is to reach the owner, or whether DreamHost can contact that user itself. The 23 October 5:20PM update does name the mail apps that will "stop accepting the old password": Outlook, Apple Mail and a phone.

One more datum is community talk, not evidence. A customer in a Hacker News thread quotes the notice as saying DreamHost has "expired the passwords for some email and FTP/SFTP users", with "no new password" set, and says the mailboxes on their own accounts still worked. If that is accurate, the expiry was not applied to every mailbox the owner holds, and an owner cannot tell from the notice which ones. It is one anonymous account, it could not be checked, and DreamHost's page does not address it. The same thread contains guesses about a cause. DreamHost has said nothing that supports any of them, and this briefing does not repeat them.

What the record does not establish

Technical details

DreamHost's pages print no indicators of compromise, no hashes, no IP addresses, no domains used by an intruder, no CVE or software version, no log lines and no configuration change. This section therefore holds only what the pages do print: the addresses and menu paths a customer is told to use, the propagation delay, and the component states. Addresses are defanged here so that none is a live link; type the real address yourself rather than following any link in an email, as DreamHost advises.

Control panel:            panel[.]dreamhost[.]com
Email passwords:          Mail > Manage Email
FTP/SFTP passwords:       Websites > SFTP Users & Files
Time to take effect:      up to 15 minutes
Email and FTP users:      contact your account owner, who can set a new password
File Manager (offline):   files[.]dreamhost[.]com
DreamHost's rule:         will never email you asking for your password; the notification will not ask you to log in through a link
If you did not ask for a reset email:   you can ignore it

The help article that update 2 links, on changing a mail user's password, says the change is made from the Manage Email page in the panel, or from the mailboxes panel if the current password is known, and not in Webmail. It gives the generated strong password option as one of two choices. This is the vendor's general documentation, read 26 October, not a statement about this incident.

Incident title:   Investigating an incident affecting File Manager and Webmail
Incident status:  Service Disruption
Components:       Web Services, Email Services
Locations:        File Manager Interface, Email Hosting, Webmail Interface

Service Disruption:  File Manager Interface; Email Hosting; Webmail Interface
Operational:         Web Hosting; DreamPress Hosting; Domain Registrations; Security Certificates; Database Hosting;
                     DreamHost Web Panel; DreamHost Billing; DreamCompute Hosting; DreamObjects Hosting

What a defender can hunt or harden without any DreamHost indicator is listed in the checklist below. Those items are derived from general practice, not from DreamHost's pages, and are marked so.

What to do, in order

The question the page does not answer

A precaution is taken against something. DreamHost reset two kinds of credential for an unstated number of accounts, kept File Manager unavailable from update 2 to update 9, 52.2 hours (derived), and told owners to look after their own users. If those credentials were never exposed, what exactly was the precaution against, and if they might have been, why has a company that publishes nine status updates not said so in one of them?

Key facts