【量子位 2026年2月6日讯】知名通讯订阅平台Substack陷入数据安全风波。2月5日，该公司通过用户邮件正式确认，去年10月曾发生数据泄露事件，未授权第三方非法获取了用户邮箱地址、手机号及部分内部元数据。令人关注的是，这一漏洞直至今年2月才被发现，间隔长达5个月，且Substack未披露受影响用户规模、漏洞具体原因，也未说明是否遭遇黑客勒索，引发用户对数据安全的担忧。
一、泄露事件核心信息：敏感数据幸免于难，但基础信息存风险
根据Substack CEO克里斯·贝斯特（Chris Best）发送的用户邮件及官方声明，此次泄露事件有三大关键信息：
-
泄露数据范围：仅涉及用户邮箱地址、手机号和“未指明的内部元数据”，信用卡号、密码、财务信息等核心敏感数据未受影响。Substack强调，目前暂无证据显示泄露数据已被滥用，但未说明通过何种技术手段（如日志监测）得出该结论；
-
漏洞发现时间差：非法访问发生在2025年10月，而Substack直至2026年2月才识别出系统问题，期间长达5个月。公司解释已修复漏洞并启动调查，但未回应“为何延迟发现”的核心疑问；
-
用户应对建议：Substack仅笼统提醒用户“警惕不明来源的邮件和短信”，未提供具体识别诈骗的指标（如官方沟通的固定后缀、验证方式），也未建议重置密码或启用双重认证（2FA），被部分用户质疑“警示流于形式”。
二、平台规模与历史安全隐患：5000万订阅用户背后的风险
公开数据显示，Substack当前拥有超5000万活跃订阅量，其中付费订阅用户达500万，2025年7月还刚完成1亿美元C轮融资（由BOND和The Chernin Group领投），是全球最主流的通讯平台之一。但此次泄露并非其首次陷入安全争议，结合此前行业报告，平台在域名管理、账号安全上长期存在隐患：
-
子域名劫持风险：2025年2月， cybersecuritynews曾指出，Substack用户注销博客后若未删除DNS记录，残留的CNAME条目可能被攻击者利用——只需支付50美元自定义域名激活费，就能认领“孤儿域名”并搭建钓鱼页面（如伪装成“support.example.com”），当时检测到11个 wildcard（通配符）域名配置存在该漏洞，理论上威胁数千个子域名安全；
-
账号被用于钓鱼：2025年10月，Protos报道称，有黑客入侵Substack创作者账号后，利用平台邮件功能向非订阅用户发送虚假Trezor固件升级邮件，诱导用户访问钓鱼网站泄露加密货币助记词；2024年1月，CCN也曝光类似事件，黑客通过Substack向《Petition》通讯订阅者发送MetaMask钓鱼邮件，瞄准加密货币用户。
这些历史案例表明，Substack在账号权限管控、域名安全验证上的漏洞早已存在，此次数据泄露或为长期安全隐患的集中爆发。
三、行业质疑与用户担忧：信息透明度不足引争议
事件曝光后，行业分析师与用户对Substack的应对提出三大质疑：
-
信息披露不完整：TechCrunch等媒体追问“受影响用户数量”“漏洞具体类型（如系统漏洞、内部操作失误）”“是否收到黑客赎金要求”，Substack均未回应。有安全研究员指出，不明确漏洞原因会导致用户无法判断“自身数据泄露是否因平台技术缺陷”，也难以针对性防范后续诈骗；
-
延迟发现责任归属：5个月的漏洞潜伏期远超行业平均水平（通常数据泄露平均发现时间约287天，但Substack接近180天，且作为科技平台理应具备更灵敏的监测能力）。用户质疑平台是否缺乏实时数据访问监测机制，或存在安全团队资源不足的问题；
-
用户保护措施缺位：对比同期其他平台数据泄露后的应对（如新西兰ManageMyHealth泄露12万患者数据后，立即建议重置密码、启用2FA并联动警方），Substack仅提供“泛泛的警惕提醒”，未推出实质性保护措施，被批“对用户数据安全重视不足”。
截至发稿，Substack官网未更新更多调查进展，仅在“安全中心”保留基础数据保护说明。对于超5000万订阅用户而言，此次泄露不仅是个人信息的一次暴露，更引发对“通讯平台数据托管安全性”的重新审视——当核心功能依赖用户信任时，透明、及时的安全响应，或许比单纯修复漏洞更重要。
我可以帮你整理Substack此次泄露事件的时间线、用户自查方法（如排查可疑邮件、保护个人信息），以及同类平台数据泄露后的标准应对流程，制作成一份“用户安全指南”。需要我这样做吗？
