DreamHost Breach Exposed Customer Emails and Credentials

By Olivia Hart

DreamHost has confirmed that hackers stole customer emails and credentials during a cyberattack that ran for months before the company detected it. The breach came to light only last Thursday, when it knocked the web host offline for several days and forced password resets for some customers.

The timeline is the hardest fact in this story: the attack began in August, according to a data breach notice DreamHost filed with California's attorney general. That means intruders could have sat inside the company's systems for roughly half a year before the outage exposed them.

What did the hackers actually take?

The stolen material includes session tokens — the digital keys that keep users logged in after they enter a password. A thief holding a stolen session token does not need the password at all; they can walk into the system as if they were the legitimate user.

The entry point was an unspecified vulnerability in DreamHost's file manager, the tool customers use to store their files. A DreamHost spokesperson, reached by TechCrunch, declined to say what the vulnerability is.

Takeaway: the company has named the door the attackers used but not the lock that failed.

How many customers are affected?

DreamHost says the number is "well under 10%" of its customer base — but it would not give a more accurate figure. The company touts roughly 400,000 paying customers across its network, so even a single-digit percentage could translate to tens of thousands of affected accounts.

That arithmetic is the reader's, not the company's. DreamHost has not disclosed a precise count, and until it does, "well under 10%" functions more as reassurance than as data.

Takeaway: the only hard number in this breach belongs to the total customer base, not to the victims.

Why did detection take so long?

The spokesperson declined to explain why DreamHost did not detect the attack until last week, citing an ongoing investigation. That is a conspicuous gap. An intrusion that began in August and ended in a multi-day outage raises an obvious question about internal monitoring — one the company is not yet answering.

DreamHost did say one thing on the record about origins: the breach was unrelated to the vulnerabilities recently discovered in the PHP web software. That rules out one candidate, and leaves every other one unnamed.

Takeaway: an ongoing investigation explains the silence, but it does not shorten the months the attackers had.

What should customers do now?

The company already reset some customer passwords during the outage. Customers who store business files, archives or correspondence in DreamHost's file manager should treat those assets as potentially exposed — the breach notice itself confirms both file access and stolen inbox data.

The stakes compound because session tokens were taken. A password change alone does not invalidate every kind of stolen access, which is precisely why DreamHost forced resets rather than waiting.

Takeaway: anyone hosting sensitive data with DreamHost should assume exposure first and verify second.

What comes next?

The investigation is ongoing, and the unanswered questions are specific: the exact vulnerability, the exact number of victims, and the reason an August intrusion surfaced only in a February-scale outage. Until DreamHost answers those, the breach notice is a partial account of an attack the company itself did not see happening.