Apify 检测到在 2026 年 11 月 9 日至 10 日期间,有未经授权的第三方利用受损的凭据访问其内部系统以及大量的账户凭据。该泄露事件于 11 月 11 日被发现,随后公司切断了攻击者的访问权限,并启动了针对所获取数据范围的全面调查。

检测与立即响应

Apify 于 11 月 11 日 12:13 UTC 识别出未经授权的活动。在检测到活动后,公司作为预防措施撤销了多个与外部集成(包括 GitHub)的 OAuth 连接。

虽然调查并未发现这些撤销的连接被用作攻击向量,但公司更换了各种关键的内部密钥,并在系统中增加了额外的监控。

“API 令牌现在仅以哈希形式存储,这限制了任何类似事件的影响。”

— Security incident

基础设施加固与缓解

为了降低未来发生此类事件的风险,Apify 更新了其架构,现在 API 令牌仅以哈希形式存储。此项更改旨在限制任何类似基于凭据的攻击的影响。

公司还实施了新的安全层,包括内部服务之间的网络限制以及内部系统的更强身份验证协议。目前正在对整个技术栈进行全面的安全审查。

用户操作与数据隐私

Apify 建议用户通过导航至“设置”并将“通用资源访问”设置为“受限”来限制对他们存储的访问。如果没有此设置,任何知道存储 ID 的人都可以读取该存储。

要求从私有 GitHub 仓库构建 Actors 的用户通过在 Actor 设置中选择“更改提供商”来重新连接其 GitHub 账户。Apify 已表示,它不会联系尚未被确定为受泄露影响的用户。

剩余的不确定因素

初始凭据受损的具体根本原因仍在调查中。Apify 已承诺在事件发生后的一周内发布一份详细说明根本原因和修复步骤的事后分析报告。

Hacker News 读者的反应

  • 替代方案: 一位评论者建议 Bleeping Computer 的报道提供了关于 Apify 响应的更多具体细节,例如 API 令牌的轮换和 2FA 重置。 评论 ↗
  • 质疑: 一位评论者对公司的安全实践表示怀疑,质疑为什么 API 令牌之前没有以哈希形式存储。 评论 ↗
  • 疑问: 另一位用户指出,公司在泄露中包含的具体数据类型方面缺乏透明度。 评论 ↗

以上为 Hacker News 讨论中观点的摘要,并非经过核实的事实。 阅读完整讨论 ↗