A customer-side verification workflow for hosted domains after DreamHost

The hardest part of a provider breach is translating a broad notice into a verified customer answer. DreamHost has stated that a File Manager vulnerability exposed FTP/SFTP credentials for users who logged in during a defined window and that a limited number of webmail sessions were involved. It has not published a list of affected customer domains. Customers need a repeatable way to move from the notice to their own evidence.

Step one: define the population

Create a list of domains, hosting accounts, SFTP users, mailboxes, and delegated administrators connected to DreamHost. Add the business owner for each item. Mark accounts that may have used files.dreamhost.com during the period from approximately August 2026 through October 23, 2026.

Do not start with a public search that returns every DreamHost-related asset. Start with the accounts you control. The external search is a reconciliation step, not the population definition.

Step two: inventory the public surface

On November 15, 2026, ZoomEye returned 28 all-scope observations for domain="dreamhosters.com" and 122 for domain="dreamhost.com". The staging-domain HTTP intersection returned 15. DreamHost documents the staging namespace for customer use, while dreamhost.com is the provider's own domain.

Use these observations to ask whether the organization knows about every visible domain and service. Do not use them to decide that a specific account was compromised. A public domain match does not prove which user entered credentials into File Manager.

Step three: test account controls

For each potentially exposed user, confirm that the password was replaced, active sessions were ended, stored client passwords were updated, and the old password fails. Review mailbox forwarding, filters, recovery settings, and application connections. Review website files against a clean deployment or backup.

Document the evidence for each check. A screenshot of a password-change screen is weaker than a timestamped test showing the old credential fails and the new credential works from the expected client. For file checks, record the baseline, the hashes or differences, and the owner's disposition.

Step four: follow the downstream path

Check whether the hosting email address is used for password recovery at source control, cloud, financial, or administrative services. If it is, review those accounts for new sessions, tokens, devices, or recovery changes. The goal is to find secondary access that a hosting reset cannot close.

Where an account is shared by a team or agency, verify every named person and every automation job. A reset that covers only the primary owner can leave a delegated user with an obsolete but still valid path on another system.

Step five: classify the result

Use three outcomes: verified clean, confirmed issue, and unresolved. "Verified clean" requires evidence from the relevant account and the customer's own controls. "Unresolved" records the missing evidence, owner, and deadline. Avoid collapsing an unavailable log into a negative finding.

For a confirmed issue, preserve evidence and isolate the account before making broad changes. If the issue is a file change, compare it with the deployment history. If it is a mailbox rule, identify the destination and the messages affected. If it is downstream access, follow the downstream provider's recovery procedure.

Step six: close the loop

Update the asset inventory with what the review found. Add the provider contact, account owner, and notification path to the hosting record. Set a review date for delegated users and stored credentials. If a customer cannot produce a reliable baseline, schedule the work needed to create one.

The useful outcome is not a count that sounds alarming. It is a defensible answer for each hosted domain: what was visible externally, what was exposed by the provider, what the customer verified, and what remains unknown. DreamHost's incident supplies the provider facts; the customer must supply the account-level conclusion.

References

• DreamHost, October Security Incident
• DreamHost, Current Status Notifications
• DreamHost, FTP and SFTP at DreamHost
• DreamHost, Keeping your website secure
• BleepingComputer, DreamHost confirms data breach