DreamHost data breach: what to check on your WordPress site now

Originally published at hamzaahmadaslam.com.

How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.

The DreamHost data breach exposed FTP/SFTP credentials and some webmail accounts, putting affected WordPress sites at risk of unauthorized changes. Start by checking DreamHost's reset notice and securing your file-access and email accounts. Then inspect your WordPress users, configuration, files and access logs before deciding whether your site needs malware removal.

What DreamHost confirmed about the data breach

On October 29, 2026, DreamHost confirmed a security incident involving its browser-based File Manager at files.dreamhost.com.

An attacker exploited a vulnerability in the third-party software behind File Manager. DreamHost says the attacker obtained FTP/SFTP usernames and passwords belonging to users who accessed File Manager between approximately August 2026 and October 23, 2026.

The attacker also reached certain webmail systems and obtained credentials for a limited number of users. DreamHost believes mailbox contents may have been viewed in a small number of cases.

DreamHost says:

• It discovered the unauthorized access on October 23 and immediately took File Manager offline.
• It reset affected webmail passwords and ended sessions that day. Reset notices for email and FTP/SFTP accounts went out Friday evening and through the weekend.
• It found no evidence that panel logins or customer billing details were accessed.
• Its investigation indicates that well under approximately 10% of hosted email and FTP/SFTP accounts were affected.
• The incident was unrelated to the recent PHP security updates.

DreamHost's October 25 status notification confirmed that some mail, FTP and SFTP passwords had been expired.

TechCrunch reported the incident on November 4, describing stolen session tokens, customer files and mailbox access. DreamHost's public announcement confirms the credential exposure but does not establish that every affected website's files were read or changed.

The exact customer count remains unpublished. DreamHost has not identified the vulnerable File Manager software.

How to tell whether your DreamHost account was affected

Check these signs:

1. DreamHost sent a reset email. The company notified account owners whose email or FTP/SFTP users might have been affected.
2. Someone used File Manager during the exposure window. If you or another user logged into files.dreamhost.com between approximately August and October 23, treat that user's FTP/SFTP credentials as compromised.
3. A mailbox stopped accepting its old password. DreamHost expired passwords for mailboxes it believed might have been affected.

A reset email alone does not prove exposure. DreamHost says its investigation indicates no action is currently required if you received no notice, although it suggests precautions.

If an unchanged FTP/SFTP or email password still works, DreamHost says its investigation to date indicates that credential was not exposed. It still recommends changing the password as an added precaution.

Ask anyone managing your hosting whether they used File Manager during the affected period. Contact DreamHost support if you cannot identify which users were involved.

Type panel.dreamhost.com into your browser yourself. Never enter passwords through an unexpected email link.

Change your DreamHost account passwords first

Complete these account steps before changing WordPress credentials.

1. Reset every website user's password

Open the SFTP Users & Files page in your DreamHost panel.

For each SFTP or Shell user:

1. Find the username.
2. Select Login info, then Change password.
3. Generate a strong password or enter a unique one.
4. Select Reset Password.

SFTP means Secure File Transfer Protocol. It allows file transfers between your computer and the server. A Shell user can also access server commands through SSH.

DreamHost's incident notice identifies FTP/SFTP credentials. Checking every website user is a precaution, especially where accounts or passwords are shared.

Record which websites each username can access. Inspect those sites if the account may have been exposed.

Allow up to five minutes for the new website password to work.

2. Reset your DreamHost email passwords

Open the Manage Email page.

For each mailbox:

1. Find the email address and select Manage.
2. Scroll to Change Password.
3. Generate or enter a unique password.
4. Select Save Changes.

Include mailboxes used for WordPress administration and business correspondence.

Send new credentials through a separate trusted channel. Avoid sending passwords to a mailbox that may have been accessed.

3. Check forwarding rules and mail filters

After resetting mail passwords, inspect forwarding settings before resetting WordPress administrator passwords.

On the Manage Email page, review forwarding destinations. Remove any unauthorized address after preserving the details.

Open the Message Filters page, then select Edit beside each mailbox. Inspect rules that redirect, delete or hide security messages.

For mailbox-level filters, DreamHost also provides mailboxes.dreamhost.com under Email Filters.

Do not convert a fully hosted mailbox into a forward-only mailbox as a security shortcut. That conversion can delete stored messages.

4. Enable multifactor authentication for your panel

Open the Security page and locate Multifactor Authentication.

Follow the setup prompts for an available authentication method. Store your recovery codes securely.

Multifactor authentication, or MFA, requires a separate verification code alongside your password. DreamHost's MFA documentation confirms this protects panel access. DreamHost-hosted email does not support the same MFA feature.

On the Security page, review the Active Sessions list and its IP addresses. If you find an unfamiliar session, use End all sessions except this one. This ends every other panel session, including legitimate ones.

5. Update saved credentials and reused passwords

Update stored passwords in:

• SFTP and FTP clients such as FileZilla.
• Email applications on computers and phones.
• Deployment tools and scheduled jobs.
• Password managers and other approved credential stores.

Change any password reused on another service.

Changing an SFTP password does not change WordPress login or API credentials. Review stored WordPress application passwords separately using the WordPress application passwords guide.

Check what stolen SFTP access could mean for WordPress

A stolen SFTP password can let an attacker read or change files within that user's permissions.

If the account can access your WordPress installation, an attacker may read wp-config.php, replace existing files or upload a PHP backdoor. A backdoor is a script that provides unauthorized access.

The configuration file commonly contains database credentials and authentication secrets. If an attacker also obtains usable database access, they may change WordPress records, including administrator accounts.

These are possible consequences of stolen credentials, not confirmed actions against your site.

1. Change the WordPress database password

Find your database credentials in wp-config.php. Look for DB_NAME, DB_USER, DB_PASSWORD and DB_HOST.

Preserve a secure backup of your configuration and database before making changes.

In the panel:

1. Open the MySQL Databases page.
2. Find the database used by WordPress.
3. Select its database username.
4. Enter and save a new password.

Update DB_PASSWORD in wp-config.php to match. DreamHost's MySQL password instructions confirm both steps are required.

Use updated SFTP credentials to edit the file. Do not put configuration copies in a public website directory.

Check that the homepage and admin login work. If WordPress reports a database connection error, verify the new password. Update other applications sharing that database user.

2. Regenerate WordPress authentication keys and salts

WordPress stores authentication keys and salts in wp-config.php. Someone who copied them may have information that should no longer be trusted.

Changing these values invalidates existing WordPress login cookies, requiring users to sign in again.

If WP-CLI is available, run this from the WordPress installation directory:

wp config shuffle-salts 

WP-CLI manages WordPress through server commands. This command changes wp-config.php, so preserve a backup first.

Without WP-CLI, a developer can replace the authentication key and salt definitions using the WordPress secret-key service. Leave unrelated configuration values intact.

3. Review WordPress administrator accounts

In WordPress, open:

Users > All Users

Filter by Administrator. Check each username, email address and assigned role against your records.

Investigate unfamiliar accounts or unexplained role changes before removing access.

After securing the associated mailbox, change WordPress administrator passwords. Also review the administrative email address under Settings > General.

A compromised mailbox can receive WordPress password-reset messages for accounts registered to that address.

For WooCommerce stores, inspect accounts with store-management permissions as well. They may have significant access without being administrators.

4. Check WordPress core and plugin files

Compare installed WordPress files with their published release checksums.

A checksum is a calculated file value. A mismatch means the file differs from the expected version, which may indicate an update, customization or unauthorized modification.

WP-CLI can verify WordPress core and plugins. Its plugin checksum documentation confirms the --all option.

Custom and commercial plugins may lack WordPress.org checksums. Compare them with trusted packages or your version-control history.

Inspect active themes and must-use plugins separately.

5. Review recently changed PHP files

PHP files contain code executed by the server. Unexpected PHP changes may indicate a backdoor or altered application code.

Search for files modified since August 1, 2026. Compare suspicious results against your backups, deployment history and approved updates.

Pay attention to:

• wp-content/uploads, where unexpected executable PHP deserves investigation.
• Plugin, theme and wp-content/mu-plugins directories.
• The WordPress installation root and .htaccess.

Inspect .htaccess for unfamiliar redirects or server rules.

Modification dates alone cannot establish compromise. Normal updates change them, and an attacker may manipulate timestamps.

6. Review recent access logs

Open the Manage Websites page in DreamHost. Select Manage for your site, open the Logs tab, then the Access Logs tab.

DreamHost's access log documentation confirms that the panel retains logs for up to seven days and displays the first 200 results per search.

Look for unusual requests to login pages, administrative endpoints and suspicious PHP paths.

You can also inspect logs using SFTP under the user's /logs directory, followed by the site and HTTP or HTTPS directory. DreamPress uses a different layout.

DreamHost's default HTTP log retention is seven days. On November 7, ordinary retained logs will not cover most of the incident window.

HTTP logs record website requests, not necessarily SFTP logins. Ask DreamHost support whether older records are available if you need to investigate file-access activity.

Run these read-only WordPress checks over SSH

If your account has Shell access and WP-CLI is installed, connect with updated credentials.

Open the directory containing wp-admin and wp-content, then run:

# Run from the WordPress installation directory. # List WordPress administrators. wp user list --role=administrator # Verify WordPress core files. wp core verify-checksums # Verify plugins against WordPress.org checksums. wp plugin verify-checksums --all # List PHP files modified since August 1, 2026. find . -type f -iname '*.php' \ -newermt '2026-08-01 00:00:00' -print # List PHP files anywhere inside uploads. find wp-content/uploads -type f \ -iname '*.php' -print 

These commands do not intentionally change website files or database records. The user-list command loads WordPress and may execute installed code. Checksum commands may contact WordPress.org.

The -newermt option uses GNU find and compares modification times using the server's time zone.

What to expect:

• Administrator list: every account should have an authorized owner.
• Core checksums: mismatches or unexpected files need investigation.
• Plugin checksums: unavailable checksums require a trusted source comparison.
• Modified PHP: compare changes with approved deployments.
• PHP in uploads: investigate unexpected scripts regardless of their dates.

A successful checksum check cannot rule out database changes, modified custom code or previously removed backdoors.

Without WP-CLI, inspect administrators through WordPress and compare files through SFTP. Ask your developer to review suspicious changes.

Copyable DreamHost incident checklist

Work from top to bottom. Record completion dates and findings in your own copy.

This checklist describes a procedure, not tests performed or results observed.

What to do if your WordPress checks find suspicious changes

Stop unrelated updates while preserving evidence.

Save suspicious file paths, command output, logs and copies of modified files outside the public website directory.

If you find unauthorized administrators, executable PHP or unexplained core changes, treat the site as potentially compromised.

A backdoor may remain after password rotation. Removing one suspicious file may leave another entry point.

For WooCommerce stores, consider restricting sensitive administrative activity while investigating potential access to customer or order information.

Do not restore a backup over the live installation before preserving evidence. Older backups may contain compromised files.

Use the warning signs of a hacked WordPress site to identify further evidence.

Full recovery requires checking the entry point, replacing compromised code, examining database changes and validating the recovered site.

What remains unknown as of November 7, 2026

DreamHost has not publicly identified the vulnerable third-party File Manager software or supplied a named vulnerability identifier.

It has not published an exact number of affected customers or websites. Its percentage estimate concerns email and FTP/SFTP accounts, so it cannot be applied directly to WordPress installations.

The public announcement also does not establish which individual websites had files read or modified.

DreamHost says its investigation continues and affected users are being contacted. Formal notices may provide details absent from the public announcement.

Review any account-specific notice alongside the public updates.

Your next step if you find a compromised site

Finish credential rotation and preserve suspicious files and logs.

If the evidence points to unauthorized code or account changes, request WordPress malware removal and recovery instead of deleting files at random. Supply the investigator with your checklist, affected usernames, file paths and available logs.

If your checks find nothing suspicious, keep the results, monitor administrator activity and follow DreamHost's incident updates.