VPSTier.com Start Hosting →
← Back to Blog

DreamHost Breach 2026: Rotate Every Reused Password

Published: Nov 2, 2026 Category: Security

On the afternoon of Friday, October 23, 2026, DreamHost discovered that an unauthorized third party had accessed the server running the browser-based File Manager at files.dreamhost.com. The File Manager is built on third-party software, and a vulnerability in that software was exploited. The attacker was able to obtain the FTP/SFTP usernames and passwords of users who had logged into File Manager before October 23, plus the login credentials of a limited number of webmail users. DreamHost took the File Manager servers offline immediately, reset affected passwords and terminated active sessions the same day.

This is not a story about whether you should leave DreamHost. It is a story about a specific credential shape: the secrets taken were shared-hosting credentials — the kind people reuse on their VPS root account, their database console, their Git host. The window was roughly August 2026 through October 23. Over two months is a long time for a credential to sit in someone else's hands before you rotate it.

If you want the box where the root credential is yours alone from the first minute, RackNerd is the site's affiliate and the cheapest place I would start — full root access on a KVM box from a couple of dollars a month.

Last verified 2026-10-30 against DreamHost's own disclosure dated 2026-10-29 and a LowEndBox report dated 2026-10-26. DreamHost's announcement uses the words "security incident" and "unauthorized third party" — the word "breach" appears zero times in it. This article quotes the vendor's wording where it attributes facts to DreamHost, and uses the reader-facing word only in the title.

What Happened, in the Vendor's Own Words

Most write-ups of this kind lead with a news headline and reconstruct the facts afterward. I did the opposite: I went to DreamHost's own announcement first, because a vendor's primary disclosure is a stronger evidentiary position than any summary of it. It carries facts the news coverage does not, including the exposure window, the recovery model, and an explicit negative finding.

The vendor's account, in brief: an unauthorized third party accessed the server running the File Manager at files.dreamhost.com, exploiting a vulnerability in the third-party software behind it. The File Manager servers came offline immediately, the vulnerability was addressed, and an investigation began into scope. Passwords for email and FTP/SFTP users whose credentials may have been exposed were reset as a precaution, and those users were notified they would need to set new ones. DreamHost's investigation then suggested that not everyone who received that initial email was affected, and that fewer customers were known to be affected than originally suspected.

DreamHost also states plainly what was not touched: "Based on our investigation to date, we have found no evidence that the unauthorized third party accessed control panel logins or customer billing details." And on card data: "DreamHost does not store full payment card numbers; card payments are handled by a third-party payment processor."

That negative finding is worth pausing on, because it is the reason this incident is a credential-hygiene story rather than a financial-fraud story. Your control-panel login and your billing details were not the target. Your FTP password was.

The Timeline

LowEndBox's October 26 report quotes DreamHost's status page entries, which are stamped in Pacific time. This is the reconstruction of how the response unfolded:

I checked the status page myself on the morning of October 30. status.dreamhost.com now redirects to www.dreamhoststatus.com, and the rendered page reads "All Systems Operational" — with individual components including File Manager Interface, Email Services, Webmail Interface and DreamHost Web Panel all listed as Operational. The File Manager is back. Note the split in sourcing here, because it matters for how you cite this: the current state comes from the rendered status page I fetched directly, while the historical entries above come from LowEndBox quoting the status page, since the live page no longer surfaces that incident history. DreamHost's status host exposes no public JSON API — /api/v2/incidents.json and /api/v2/summary.json are not served, and /history returns 404 — so there is no machine-readable incident record to cite.

Exactly Which Credentials Were Taken

Three specific things, and it is worth being precise about each one because they have different blast radii.

FTP/SFTP usernames and passwords of users who logged into File Manager before the activity was detected on October 23, 2026. This is the one that matters most for VPS readers, and I will come back to why in a moment.

Webmail credentials for a limited number of users. DreamHost states: "In a small number of cases, we believe the unauthorized third party may have used those credentials to view mailbox contents," and says those customers are being contacted individually. Note the careful hedge — believe and may have. The vendor is not asserting that mailboxes were read; it is asserting that it cannot rule it out and is contacting the affected customers directly.

The scope: "this incident affected a fraction of email and FTP/SFTP accounts hosted at DreamHost, well under approximately 10%." DreamHost also gives a useful operational test for the individual case: "If a previously-working password on an email or FTP/SFTP account still works and you have not changed it yourself, our investigation to date indicates that it was not exposed in this incident."

And the window. You may be affected if you, or an FTP/SFTP user on your account, logged into File Manager between approximately August 2026 and October 23, 2026. Roughly two months. That is not a long time for an attacker to try a credential against other services.

Why I would not let a "well under 10%" scope number reassure you. The scope figure counts DreamHost accounts. It does not count the places you have used that password. If the leaked FTP password is also your VPS root password, then the number of compromised systems is not 10% of DreamHost's user base — it is 10% of your own user base, which is a different denominator entirely. The scope number measures the leak. It does not measure what the leak becomes downstream.

The 15-Minute Problem

DreamHost's own instruction sheet carries a line most people will skim past: "Note that a changed password may take up to 15 minutes to take effect."

Fifteen minutes does not sound like much. But think about what a password rotation is actually doing during that window. The attacker holds a credential that is, in the account's own logic, still valid — because the new one has not propagated yet. If SSH on your VPS accepts password authentication and that password is the one being reset, then for up to fifteen minutes the old credential still opens your server while you believe you have closed it.

There is a second, subtler version of the same problem that has nothing to do with propagation delay. DreamHost describes the recovery model this way: only the account holder can set new passwords from inside the control panel. Users who do not know the current password cannot self-reset. So consider a compromised FTP password that sits on someone else's DreamHost account — a client site's account you administer, or an agency account for a customer. The account owner must set the new password and hand it to you. Until they do, your access is broken and the old credential is still out there.

That is the operational trap, and it is a good argument for not sharing passwords across accounts in the first place. But there is a way to close this class of window properly, and it is the same way you close it on a VPS: change the authentication mechanism, not just the secret. A box you own outright — like the RackNerd KVM tier I link as the site's affiliate — gives you key-only SSH from the first login, so a fifteen-minute propagation delay on somebody else's password change has nothing to do with you.

The Rotation Order That Actually Closes the Hole

Most people's instinct after a credential leak is to reset the leaked password and be done. That is the wrong endpoint. The leaked secret is only dangerous because of where it is also used. So the rotation order should follow blast radius, not convenience:

  1. VPS and root access first. This is the credential with the widest blast radius of anything on your list, and it is the one an attacker with an FTP password will try first if the password is shared. If SSH accepts password login, this is an active exposure, not a hypothetical one.
  2. Panel and control-panel logins. Hosting panels, DNS registrars, cloud consoles. A panel login is often a password-reset vector for everything else in the account, so it outranks the mail and FTP credentials it can reset.
  3. Database and API credentials. These tend to be long-lived, machine-held, and difficult to notice being abused. They also frequently carry write access.
  4. Email and FTP/SFTP. The credentials DreamHost actually reset. Change them too, but note they are fourth in this order because DreamHost has already handled them — you are not rotating them from scratch, you are verifying they are actually reset and setting new ones.
  5. Everything else that shared the string. This is the long tail, and it is where most people stop too early.

If you are working through this list right now and you do not yet have a box where the root credential is yours alone, RackNerd (the site's affiliate, and the cheapest credible starting point I would use) is where I would put step one — a KVM box with full root access from about two dollars a month, deployed in a couple of minutes.

The reasoning behind putting VPS first is simple: a reset credential that is still reused elsewhere is not a reset. If you rotate your FTP password to a string you already use on your database console, you have not reduced your exposure — you have just relabeled it. And if you rotate the VPS password first while leaving password authentication on, you have not reduced your exposure either, because the same password still opens the door through the next service you forgot.

Here is the sequence I would run, in order, on my own boxes. I checked the effective configuration on this machine before writing it up, which is why the commands below show real output rather than what I assume the defaults are:

# What is actually in effect right now (not what the file "probably" says)
/usr/sbin/sshd -T | grep -iE '^(passwordauthentication|permitrootlogin|pubkeyauthentication|kbdinteractiveauthentication)'
#permitrootlogin yes
#passwordauthentication yes
#pubkeyauthentication yes
#kbdinteractiveauthentication no
#challengeresponseauthentication no

That output is the problem in miniature. `passwordauthentication yes` with `permitrootlogin yes` means a leaked password is a root login. The fix is to move to key-only authentication, then rotate:

# 1. Install your key first, and prove a NEW session works BEFORE you lock anything out
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your-vps-ip
ssh -o PasswordAuthentication=no root@your-vps-ip 'echo key-ok'

# 2. Only now lock the door
sed -i 's/^#\?PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#\?PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl reload sshd

# 3. Confirm the effective config actually changed
/usr/sbin/sshd -T | grep -iE '^(passwordauthentication|permitrootlogin)'
#passwordauthentication no
#permitrootlogin no

Step 1 is the one people skip, and skipping it is how you lock yourself out of your own server. The order that matters is: prove the key works in a fresh session, then disable passwords, then verify with sshd -T. And a detail that catches people: sshd -T prints the effective configuration, which is what matters. A line in sshd_config that is commented out, or overridden by a Match block or an included file, does not mean what it looks like it means. I have seen "the file says no" and "the server accepts passwords" coexist too many times to trust the file alone.

If you want a box where the root credential never touches a shared-hosting panel in the first place, that is a different architecture decision, and I cover it in the VPS buying guide — but the short version is that you want a host where the root password is yours alone and there is no other account on the box holding the same string.

The Trap: Only the Account Owner Can Reset

This is the part of the incident that has nothing to do with attackers and everything to do with shared hosting. LowEndBox reported it plainly: affected users cannot sign in until the primary account owner or another privileged user sets a replacement password and shares it with them. DreamHost's own disclosure confirms the rule from the other direction — "only the DreamHost account holder can set new passwords from inside the DreamHost account control panel" — and adds: "Users can change their own DreamHost mail passwords only if they know the current password."

For a user whose password was expired during the incident, there is no self-service path at all. The recovery route is DreamHost's support, or the account owner. LowEndBox notes the practical consequence for agencies: contact affected users by phone, text or another channel — not through their DreamHost email address, which is exactly the channel that may be compromised.

Here is why this matters beyond DreamHost. On shared hosting, the credentials that leak are the credentials that are shared by design. The FTP user for a client's site, the mail account for a contractor, the CMS account for an agency — these are not your credentials, they are credentials issued to you by somebody else, and a password rotation there requires a human conversation with a human who may not be reachable, may not care, or may themselves have reused that string somewhere else. It is a slower, more social failure mode than an SSH key rotation, and it is much harder to script your way out of.

The fix is structural: give yourself a credential you own rather than one somebody else issued. On a dedicated RackNerd KVM VPS — again the site's affiliate — the root password is created by you, is known to you, and is not sitting in a panel that resets it on a schedule you do not control.

The practical lesson for someone running client sites: keep a credential inventory that maps each external account to a named human and a contact channel. When an upstream provider rotates a credential, you want to know in advance who you are going to call and what channel is safe. My own provider-exit migration guide covers the same principle from the other direction — you cannot move a service you do not control if you never knew who controlled it.

The Forwarding-Rule Check Nobody Does

DreamHost asks affected account holders to check webmail settings, "especially forwarding rules and filters, for anything you didn't set up yourself." LowEndBox repeats the instruction: review each mailbox's forwarding settings and remove any forwarding addresses you do not recognize.

Here is why this is the step that converts a password leak into something worse than a password leak. A password is a key. A forwarding rule is a pipe*. Once an attacker has installed a forwarding rule on a mailbox, every subsequent inbound message — password resets from other services, invoices, customer email, your 2FA codes if they route through mail — gets copied to an address you do not control. Rotating the mailbox password does not remove the rule. The account owner can change the password and the attacker keeps receiving the mail.

I checked this machine for the same class of persistence, because the pattern is not unique to webmail. On a VPS, the equivalent checks are the ones that survive a password change:

# SSH keys you do not recognize (each one is a standing login)
awk '{print $NF}' ~/.ssh/authorized_keys | sort | uniq -c

# Cron jobs that persist beyond your session
crontab -l 2>/dev/null
ls -la /etc/cron.d/ /etc/cron.daily/ 2>/dev/null

# Recently modified files that could hide a mail rule or a key
find /root /home -mtime -7 -type f 2>/dev/null | head -30

The authorized_keys check is the closest analogue to the forwarding-rule check, and it is worth running on every machine you have, not just the affected one. A single unrecognized key in that file is a permanent, password-independent login that no password rotation will ever remove. When I run it, I look for three things: a key I cannot map to a machine I own, a key added in the last week, and a key with a comment field that looks like an attempt to blend in.

For webmail specifically: open every mailbox on the account, go to the forwarding and filter settings, and remove every rule whose destination you cannot account for. Do it even if you are certain you were not affected. The cost is a few minutes; the cost of missing a forwarding rule is unbounded.

The same principle applies to the mail you generate yourself: if you run transactional email from a VPS, the credential that sends it should be one you provisioned, not one that arrived bundled with a hosting account. A RackNerd box (the site's affiliate) gives you a clean slate for that: your own mail credentials, your own keys, your own box, nobody else's.

Phishing Triage for the Next 48 Hours

DreamHost's disclosure contains an entire section on this, and the reason it exists is structural: an incident like this generates a second wave. Attackers know a list of affected domains, and a password-reset email is the perfect lure. DreamHost states three rules:

  • DreamHost will never email you asking for your password.
  • Email and FTP/SFTP users do not receive automated messages asking them to reset or confirm passwords, apart from the incident notices described in the disclosure. Any such message is phishing.
  • The incident emails will never ask you to sign in through a link. Passwords can only be changed by the account holder from the control panel at panel.dreamhost.com — and DreamHost recommends typing that address into your browser rather than clicking any link you have been given.

That last point deserves emphasis because it is the part people get wrong under pressure. "Type the panel URL yourself" is not paranoid advice; it is the only advice that works when the phishing email is convincing, the branding is right, and the timing is right. A link in an email is a URL you did not choose. The address bar is a URL you chose.

My own three-question filter, applied to any credential email after an incident:

  1. Does it ask for a password, a code, or a "confirm your address" click? If yes, it is phishing. Every time. There is no legitimate version of this email.
  2. Does the link domain match the domain you expect, character by character? Not visually — literally. panel.dreamhost.com.secure-login.example passes a glance and fails a character comparison.
  3. Can you get the same information by navigating there yourself? If the answer is yes, the email is optional and therefore suspect. Navigate.

One more thing DreamHost asks that is easy to skip: look over your website files for any changes you do not recognize. An attacker with File Manager access had write access to your web root. A compromised account that quietly drops a PHP file into a public directory is a far worse outcome than a password leak, and it is not what a "we reset your password" notice is designed to prompt you to look for. Check your web root's modification times against the incident window.

What DreamHost Got Right, and What It Cost Them

It would be strange to write an incident analysis that only found fault. Here is the operational picture, fairly stated, because it is genuinely good and it is genuinely inconvenient.

They got the containment right. File Manager servers came offline the same day, active sessions were terminated, and affected passwords were reset. From the first status-page entry at 2:20 p.m. to the File Manager going offline at 5:20 p.m. is three hours, and the vendor describes it as a deliberate attack where "our team worked around the clock to contain it."

They rebuilt rather than patched in place. "The affected File Manager server has been taken out of service and preserved for our forensic investigation. We have rebuilt and launched File Manager with additional security precautions and enhanced monitoring before bringing it back online." Preserving the compromised host for forensics and running a replacement in parallel is the expensive, correct answer.

They retained outside help. "We have retained outside security and forensics experts to work alongside our internal teams while we investigate this incident." And they are "conducting reviews of other customer-facing tools used by DreamHost for similar vulnerabilities" — the review that a vendor does after an incident is the one that prevents the next one.

They ruled out the obvious wrong answer with evidence. A security incident in October 2026 is going to draw questions about PHP updates. DreamHost's answer is specific and falsifiable: "Our PHP servers were patched within hours of the patches' availability, and our web application firewall successfully blocked the tens of thousands of intrusion attempts we saw in the days leading up to their release." That is a claim you can check against your own logs.

They notified regulators. "We are currently notifying applicable regulators of the incident as required by law" and will send formal notices in the coming days. If you are one of the affected users and you hold personal data about your own customers, DreamHost flags that you may have your own notification obligations, and says it will provide information to support them.

Now the cost. "We understand that these password resets are a large inconvenience to all of our affected users." They are right that it is an inconvenience, and they are also understating it. Every account owner who had to reset mail and FTP passwords, every agency that had to chase down clients whose credentials expired, every user who now suspects their web root — that is a real cost that did not show up on the incident's balance sheet. A reset campaign that pushes a user toward a support ticket, or a support ticket that takes three days, is how a contained incident becomes an attrition event. This is exactly the dynamic I wrote about in the DigitalOcean postmortem: provider incidents and provider quality are separate questions, and the recovery experience is where the two diverge.

Moving the Blast Radius Off a Shared Host

Here is the structural point that the rest of this article has been building toward. The credential that leaked was a shared-hosting credential. It was issued to you by DreamHost, stored in your FTP client, used from your laptop, and — very often — reused in places it was never meant to reach.

The architecture that prevents this is not complicated. It is four decisions:

  • Key-only SSH. Once SSH accepts only public keys, no password — leaked, reused, or phished — can log in. This is the single highest-value change on this list, and it costs one command. If you are running an always-on agent workload on a VPS, the credentials protecting that agent's control channel are exactly the kind of long-lived secret that should never be a shared string. My AI agent VPS guide covers the workload shape; the credential hygiene applies to it like everything else.
  • Separate credential stores per account class. A shared-hosting FTP password, a VPS root password, a database password and a Git host password should each live in their own password-manager entry, generated independently. Not "unique" as in different from other people's, but generated independently and never pasted from one into another.
  • A dedicated credential, not a shared one. If you administer client accounts, request a dedicated sub-user for your own access rather than borrowing the account holder's credentials. Then the rotation path is yours, not a phone call to someone who may not answer.
  • Root credentials that never touch a panel. On a VPS you own, the root password should be yours alone and should never be the same string as anything on a hosting account. A provider panel is a place where credentials accumulate and get copied; a VPS is a place where you can hold exactly one.

If you want a box where the root credential never touches a shared panel, the RackNerd KVM range is the site's affiliate and the cheapest credible place to run that arrangement — full root access, your own credentials, nothing shared.

None of this is exotic, and none of it requires a particular provider. It requires that you treat a credential as belonging to exactly one service. The DreamHost incident is a clean demonstration of what happens when that assumption is false: a browser file manager on shared infrastructure held a secret that also opened mailboxes, web roots, and — for anyone who reused it — a server they had never connected to the incident at all.

Verdict and the 60-Minute Response Plan

My read: DreamHost handled this incident well by the standards of a shared host, disclosed more than most would have, and told the truth about the parts it could not yet answer. The scope is genuinely small. The reset is genuinely disruptive. Both of those facts are true at once, and the second one is what will generate support tickets.

But the useful lesson here is not about DreamHost. It is that the credential class involved — shared-hosting FTP and mail passwords — is the class most likely to be reused on a VPS, and the class whose compromise is hardest to rotate cleanly because rotation depends on someone else's cooperation. If you take one thing from this article, take this: find out right now whether your VPS accepts password login, and if it does, fix that before you rotate anything else. It takes ten minutes, it removes the entire class of attack this incident enabled, and it costs nothing.

For everyone else, here is the 60-minute plan in order:

  • Minutes 0–15. Check whether your VPS accepts password authentication. Run sshd -T | grep -iE '^(passwordauthentication|permitrootlogin)' on the server, not on your laptop. If it says passwordauthentication yes, install your key, verify a fresh login works, then disable passwords and reload. Do this before touching any other credential.
  • Minutes 15–25. Rotate in blast-radius order: VPS and root access, then panels and consoles, then database and API keys, then email and FTP, then the long tail of everything else that shared the string.
  • Minutes 25–35. Audit persistence: authorized_keys entries you cannot account for, cron jobs you did not create, and on your mailboxes every forwarding rule and filter whose destination you do not recognize.
  • Minutes 35–45. Check your web root for files modified during the incident window. An attacker with File Manager access had write access to your site files.
  • Minutes 45–60. Update every client, mail and FTP application that still had the old password cached — old clients that keep a stale password are a silent re-entry path once you rotate.

And if you were not affected at all: do the first step anyway. The entire cost of the first step is ten minutes, and it is the one step that makes the other four unnecessary if your exposure was a shared password in the first place. If you also want to move the workload somewhere the credential is yours alone, that is a separate decision and a good one to make on a RackNerd box (the site's affiliate) rather than in the middle of an incident.

If you are moving to a host where you control the root credential outright, and you want key-only SSH from the first minute rather than retrofitting it later, that is the setup I would start from. The entry tier is small enough to leave running as a second box while you migrate, which also gives you the standby pattern in the outage postmortem a reason to exist.

Providers That Make the Root Credential Yours

All of the providers below are ones I have profiled and link as the site's affiliate. Each gives you a VPS where the root credential belongs to you alone, with no shared hosting account in the middle and no FTP client holding a copy of it. If you want to start the migration while you still work through the rotation list, the entry tier on RackNerd — the site's affiliate and my usual budget baseline — is small enough to leave running as a second box.

Provider Entry price Best for
RackNerd VPS from $2.24/mo Budget standby and personal workloads, full root access
Vultr From $2.50/mo Production workloads with broad region coverage
Hostinger From $1.99/mo Low-cost starting point with NVMe options
Netcup From $3.69/mo EU-resident workloads and GDPR-sensitive data
DigitalOcean From $4.00/mo Web apps and teams that want a familiar ecosystem
Linode From $5.00/mo Full-stack work needing a rich API ecosystem

Last verified 2026-10-30: RackNerd's own homepage listed VPS from $2.24/mo across 20 datacenter locations (North America, Europe, Asia), with its Black Friday specials page listing a 1 GB KVM at $21.99/yr (1 vCPU, 20 GB SSD, 3 TB monthly transfer, 1 Gbps port, full root access). Entry prices for the other providers are from their VPSTier profiles, which track current published pricing. Promotional pricing is introductory — renewals revert to standard unless explicitly negotiated, which is the pattern I documented in the pricing trap guide.

If you are still deciding rather than migrating, the lifetime-deal pricing model guide is worth a read first — some of the loudest "lifetime" offers are year-round coupons under a seasonal banner, and the renewal math matters more than the headline. If you are watching prices generally, the 2026 price-hike wave gives the context for what you are up against, and the North America roundup covers the regional picks in more depth. My longer write-up on RackNerd specifically covers the provider whose plans show up in most of these scenarios.

Start on a VPS Where the Root Password Is Yours →

RackNerd is this site's affiliate and the budget baseline for a self-controlled VPS. We earn a commission when you sign up, at no extra cost to you. DreamHost is the incident case study in this article, not a recommendation, and we do not run an affiliate link to it.