DigiCert 11 月上旬开始向客户发送泄露通知：一套用于归档客户资料的内网系统，因为 2025 年 2 月的一次服务器迁移被搬出了 VPN 隔离网段，在公网上暴露了 16 个月。外部人员利用系统里遗留的自助注册功能创建了一个免 MFA 的账号，在 6 月 27 日至 7 月 2 日之间读走了归档客户资料，含姓名、企业邮箱、电话、企业地址，其中一小部分还包含客户在证书验证环节提交的护照、驾照、水电账单等身份证明文件。
这是头部 CA 首次因「搬错系统位置」触发根计划级泄露通报，整套错误链条值得做过迁移的团队逐条对照。
事件概述
DigiCert 在 Mozilla Bugzilla 上发布了完整的事后分析（post-mortem），随后开始向客户发送通知邮件。时间线大致如下：
- 2025 年 2 月 4 日：一套内部业务应用从受 VPN 限制的网段迁移到另一个可用区，迁移同时把它暴露到了公网，且没有经过安全评审。
- 2026 年 6 月 18 日：员工在系统上发现非 DigiCert 账号，初步判断这些账号没有绑定应用、拿不到数据，因而未按数据访问事件处置。
- 2026 年 6 月 21 日：DigiCert 的托管安全研究项目收到报告，指出外部人员可以创建账号。Web 应用防火墙随后挡掉了通过外部路径的新注册。
- 2026 年 7 月 2 日：授权校验修复上线，未绑定应用的账号不再能读取归档记录。
- 2026 年 10 月 12 日：公司开始怀疑存在数据访问；10 月 19 日确认，一个未授权账号在 6 月 27 日至 7 月 2 日读取了归档客户信息。
该事件之所以必须通报，是因为触发了 Mozilla、Chrome、微软、苹果根计划的规则要求。受影响人数未公布，身份证明文件仍在清点。
技术细节
三个失误叠加，缺一不可。
第一层是网络暴露。迁移把应用从一个受 VPN 保护的网段挪到了另一个可用区，新位置对公网可达。DigiCert 的原话是，这次迁移「被当作基础设施变更处理，而不是安全变更」，因此没有触发更细的评审与签核流程。
第二层是认证豁免。这套系统的账号管理平台与 DigiCert 面向客户的产品共用，其中带有一个自助注册功能——这个功能本来是给其他应用用的，不该在内网系统上可用。DigiCert 员工访问系统要过 MFA，但通过这个意外开放的自助注册创建的账号没有绑定任何应用，也就没有套用同一套认证要求。换句话说，外部人员可以自己给自己开一个跳过 MFA 的账号。
第三层是授权缺陷。按设计，没有绑定应用的账号不应该能读到归档数据。实际存在一个授权弱点，让这类账号拿到了对客户记录的只读权限。这也解释了 6 月 18 日那次误判：团队检查的是「账号创建」这条线，判断依据是账号没有应用归属，却没有实际验证这些账号能不能取数。到 10 月才回头补做这个验证。
值得注意的是，问题被发现后并没有立刻收敛：6 月 18 日发现异常账号，6 月 21 日才收到外部报告，7 月 2 日修复上线——中间正值数据被读取的窗口。
影响评估
先说清楚没发生什么：该账号只有只读权限，不能改记录、审批验证或签发证书；日志复查未见相关签发、验证、吊销动作；CA 系统在独立网段，CertCentral 与 DigiCert ONE 未受影响；客户登录凭证未被取走。现有证书无需更换。
真正的问题在身份证明文件。企业邮箱和电话泄露只是骚扰级别，但护照、驾照、水电账单的组合足以支撑身份冒用、二次实名认证绕过，以及针对证书验证环节的社工——攻击者能准确说出「你在某年某月为某张证书提交过什么材料」，这类话术的成功率远高于普通钓鱼。归档数据还有个特点：它会在多年后仍然是敏感数据，采集时的合规目的并不能降低泄露后的风险。
DigiCert 强调本次事件与早前那次涉及代码签名证书的支持系统入侵无关，也与 2024 年那次需重签证书的 DNS 验证错误无关。
修复建议
DigiCert 已关闭自助注册、把系统收回内网、把剩余端点迁到私有网络、重置全部密码、补上账号创建与请求量告警、复核权限，并要求网络访问变更必须经安全审批。
对自建系统与自有面板的团队，这份事后分析可以直接当检查表用：
- 把「迁移/换可用区/改安全组」列入安全变更流程，评审项至少包含一句：这个系统现在从哪些地址可达。
- 盘点所有带自助注册的组件，确认没把「给别的应用用的注册入口」带进生产；注册账号默认必须绑定角色，未绑定即无权限。
- 监控不能只看「有没有异常账号」，还要看「这些账号实际访问了什么」。只验证创建、不验证访问，就是这次误判的根因。
- 归档数据做最小化：身份证明文件过了验证期就该清理或降级存放，不要为了留痕长期堆在可读系统里。