美国主机商 DreamHost 于 10 月 23 日起发生一起至今未说明原因的安全事件，部分邮件与 FTP/SFTP 账号的密码被强制过期，受影响用户必须由 DreamHost 账号所有者重新设置密码并转告，才能恢复登录。面向客户的浏览器端 File Manager（files.dreamhost.com）在离线三天后于 10 月 26 日恢复，公司称正在监控。截至目前，DreamHost 未披露事件原因、受影响账号数量，也未确认是否有邮件或文件被访问。
事件时间线
- 10 月 23 日 14:20 PDT：运维团队开始排查 File Manager 连接异常。
- 10 月 23 日 17:20 PDT：File Manager 下线，部分 webmail 用户被登出或登录报错，同时开始预防性重置部分邮箱密码。
- 10 月 23 日 22:13 PDT：状态页转入 Identified，重置范围扩大到 FTP/SFTP 用户。公司当时要求客户先不要自行改密，因为重置流程未完成前改的密码会被覆盖。
- 10 月 24 日 10:37 PDT：重置完成，账号所有者可立即设置新密码，不必再等邮件。
- 10 月 24 日 18:09 PDT：开始分批发说明邮件给受影响账号所有者。
- 10 月 25 日 11:43 PDT：绝大部分邮件已发出；部分 Professional Email 客户遇到的 “Failed to edit” 报错已修复。
- 10 月 25 日 21:32 PDT：全部受影响账号所有者已收到通知。
- 10 月 26 日：修复推送，File Manager 恢复，事件进入监控状态。
官方说了什么，没说什么
DreamHost 反复强调这是”预防性措施”，目的是”确保客户账号的持续完整性”。同时给出了几条明确的事实边界：邮件账号仍在正常收信，FTP/SFTP 数据仍保存在服务器上；网站托管与主控制面板未受影响；受影响账号的密码是被”过期”处理，没有自动分配新密码，所以单用户无法自助恢复，必须由账号所有者操作。
没有说的部分更重要：攻击者是否进入过系统、入口在哪、有多少账号受影响、邮箱与文件是否被读取、是否有数据外泄。BleepingComputer 报道称已就此向 DreamHost 询问，未获回复。
官方通知里还有一条容易被忽略的指引：请账号所有者逐个检查每个邮箱地址的转发设置，删除不认识或已停用的转发规则。公司没有解释这条建议的原因，也没有说明是否有转发规则被改动过。从攻防角度看，这条建议指向的正是最典型的邮箱接管后动作——攻击者不需要一直登录，只要加一条转发规则，就能持续看到密码重置邮件，而受害者在自己邮箱里翻不到任何痕迹。
用户侧的真实抱怨
Help Net Security 引用了 Reddit 上的反馈：有人在周五晚密码被清空，接近 48 小时后才收到通知；有人怀疑事件与当周的 PHP 漏洞有关，向客服机器人求证得到否认，但表示”持怀疑态度”。这些都不是事实判定，只说明一件事——当厂商不给原因时，用户会自己找解释，而这类解释往往比真相传播得更快。
透明度问题在这里不只是公关层面的事。受影响的是凭据，用户需要判断”要不要把复用的密码全部换掉”，而这个判断只能基于厂商披露的范围。范围不明，用户只能按最坏情况处理，成本由客户承担。
影响评估：主机商事件会顺着客户链条放大
DreamHost 自称服务超过 40 万客户、托管 150 万以上站点。对下游客户来说，影响不是”能不能登录面板”，而是几件具体的事：业务邮箱失联几个工作日，客户来信积压；FTP/SFTP 凭据失效导致自动部署流水线中断；如果凭据确实外泄，攻击者可能已潜伏一段时间，靠读取邮件获取发票、合同、重置链接，或者靠文件访问权限在站点上留后门。
值得区分的是”可用性中断”与”机密性损失”这两层。目前公开信息只支持前者，没有任何证据表明数据被读取。但密码过期这一动作本身，通常意味着厂商认为凭据可能已暴露——否则没有理由让全部相关账号同时失效。
如果你是 DreamHost 客户，按顺序做这几件事
- 直接进 panel.dreamhost.com 改密，不要点邮件里的链接。邮箱密码在 Mail > Manage Email，FTP/SFTP 在 Websites > SFTP Users & Files，改动生效最长需要 15 分钟。
- 逐条核对邮箱转发规则，删掉任何非本人设置的转发。这一条比改密码更能发现”已经被人用过”的迹象。
- 更新所有客户端里保存的旧凭据：Outlook、Foxmail、手机邮件 App、FileZilla、CI 的部署密钥、备份脚本。
- 查登录历史与文件变更：面板里的访问日志、站点目录的修改时间、有无陌生 SSH 密钥或计划任务。
- 停用明文 FTP，改用 SFTP/FTPS；能开 MFA 的地方都开。
- 新密码不要走邮箱传达。受影响用户此时可能收不到信，电话或即时通讯更可靠。
- 不要把主机商密码与站内应用、数据库、第三方服务复用。这是主机层事件最容易升级成站点失陷的原因。
再往上一层看，这类事件提醒的是供应商风险的常规处理：把”托管商级凭据”和”业务凭据”分开管理，给部署流水线准备可轮换的独立账号，以及在预案里预先写好”供应商凭据失效时谁来改、多久内能改完”。真出事的时候，这些准备比事后排查有用得多。