Theo 谈安全漏洞、被盗 API 密钥与 AI

接连不断的安全新闻让人觉得一切都遭到了入侵。但这样的说法容易误导：同时发生的是几类不同的事件。有些是常用软件披露的漏洞，有些是针对服务的攻击报告。两者都重要，却不是同一件事。

漏洞方面包括涉及 Node.js、GitLab、PHP 和 QUIC 的问题；攻击方面则包括 Railway 和 OpenCode。我尤其担心后者，也担心把这些新闻混为一谈时，一些重要细节会被忽略。

LiteLLM 需要单独区分。我把它描述为一起供应链攻击：GitHub Actions 工作流遭到劫持，恶意版本随后被发布，而不是普通代码库中的漏洞。为了集中讨论其他例子，我暂时把它放在一边。

录制期间，我还看到了 Oracle 的漏洞报告，因此把它列在已披露的 CVE 一边，而不是攻击事件一边。CVE 为漏洞提供共同的标识符，让组织能够跨产品和发行版跟踪、讨论已知问题。

10 月 21 日的 Node.js 安全更新展示了这一流程。它列出了受支持版本和依赖项问题的修复，包括 c-ares 和 OpenSSL。安全更新为用户提供升级途径；漏洞编号公开本身并不意味着每个安装实例都遭到了攻击。

我还提到一家证书颁发机构遭入侵，以及需要更新信任受影响证书的软件。实际操作中的重点是遵循相关厂商的指导，确保浏览器、运行时和其他依赖都获得所需修复。

协调披露让维护者和发行方能在细节公开之前准备修复。但补丁一旦公开，到所有人安装更新之间可能存在危险的间隔。用户还在运行旧版本时，攻击者已经可以研究改动。

许多入侵利用的是已有修复、但尚未部署的已知漏洞。及时更新操作系统、浏览器、应用和依赖，有助于缩短这段时间。我把软件可能遭受攻击的这段时间称为漏洞窗口。

窗口受多个因素影响：底层缺陷有多容易发现、交付和安装修复需要多久、利用漏洞有多难，以及成功后能获得什么权限。修补一个由单个运营者控制的服务器，与让所有用户更新应用或重新部署依赖库，难度并不相同。

我担心智能体会让大量提交的检查和安全修复的识别变得更容易，能力强的模型也可能加快对旧版本的分析。这是我对威胁变化的预测，并不是对每起事件的测量。它让部署速度和成功利用后的后果变得更加重要。

关于 PHP 问题，我展示了 FBI 网络部门的一则警告。画面中的帖子称，两个漏洞可能导致远程代码执行，并敦促组织更新受影响的安装、盘点暴露的系统并监控可疑进程。它还建议，无法立即更新时将受影响系统下线。

画面中的警告列出了 CVE-2026-109618 和 CVE-2026-109619。我认为问题严重，并讨论了一篇有关修复后的容器镜像在协调披露禁令结束前发布的报道。根据画面中的报道，PHP Foundation 称，提前发布让修复在其他发行方仍准备更新时暴露出来。

我担心提前披露会让防守方在攻击者研究修复之前，拥有更少时间部署更新。披露的顺序和时机很重要，尤其是在自动化工具可能加快分析的时候。不同团队独立发现同一缺陷，也让人更难假设只有最早的报告者知道问题。

我提到，这些 PHP 问题由较早一代模型发现，Wiz 也独立报告了它们。更广泛的意思是，这种能力并不只存在于一个研究者或一个模型手中。独立发现使协调披露和及时修补更加重要。

我也反对直接用运行 PHP 的网站总数占比衡量用户受影响程度。按网站数量统计和按流量加权回答的是不同问题，废弃网站可能影响前者。我自己打开的浏览器标签只是一个例子，不能代表整个互联网。

这并不意味着无人维护的网站没有风险。我记得曾为亲戚建立一个 WordPress 网站，后来停止维护，它就遭到了入侵。废弃网站、维护者离职后的系统以及政府服务，即使不是我每天访问的网站，也可能持续暴露在风险中。

接下来是 OpenCode。我介绍了一起涉及用户通过其控制台提供的第三方 API 密钥的事件。我提到受影响的开发者报告了未经授权的用量和账号暂停，费用从几百到几千美元不等。这些是视频中讨论的报告；暴露范围仍需以服务商的事件公告为准。

我说 OpenCode 正与服务提供商合作处理退款、恢复账号和轮换密钥。即使密钥很快就会被撤销，盗取者仍可能在短时间内使用它，这引出了一个问题：为什么有人想在几个小时内获得大量推理资源？

画面中 Railway 的披露称，未经授权的第三方可能访问了加密的客户环境变量，并取得了其中部分变量的解密内容。这些变量可能包含 API 密钥、数据库凭据和其他秘密。公告称调查仍在进行，并建议用户采取预防措施。

我在 Railway 上部署了一些服务，想轮换变量并重新部署时却遇到部署不可用，这让我很沮丧。我把凭据事件和部署中断分开讨论，并批评 Railway 的可靠性。关于中断原因的判断是我的个人看法，不是该披露已经证实的结论。

Railway 也曾是我的赞助商，我说这番批评可能影响尚未发布的广告。我喜欢它的部分定价和存储服务，但此次中断让我重新考虑把重要软件托管在哪里。对用户来说，眼前的问题是无法按预期快速恢复部署和替换凭据。

为什么要窃取很快会被撤销的密钥？我考虑了欺诈和其他攻击等可能用途，随后提出自己的假设：大量推理可能用于生成模型蒸馏的训练数据。视频没有证实这就是动机，也没有确定这些事件的攻击者身份。

我所说的蒸馏，是指利用较强模型的行为样本帮助训练另一个模型。展示智能体如何使用工具完成复杂任务的数据可能很有价值，普通网页文本中未必有足够多这样的样本。因此，寻求这种数据的实验室可能希望获得大量模型回答。

我认为，模型服务商怀疑客户在收集数据训练竞争系统时，会限制其访问。我讨论了账号限制、身份验证、使用额度和地区访问限制等可能的障碍。我对服务商动机的理解同时包含安全考虑和商业利益；这是我的看法。

我推测，被盗密钥可能有吸引力，因为它们暂时提供推理能力，费用却记在他人的账号上。我也承认自己没有那么仔细地监控 OpenAI 支出，在 Railway 事件后才去检查。这是关于动机和利益的推测，并不是某家实验室参与攻击的证据。

我进一步提出，对模型输出的需求可能让存储 API 密钥的平台更容易成为攻击目标。我没有提供证据证明 Railway 或 OpenCode 事件是为了蒸馏而实施的。还可能存在其他动机，在这里讨论的材料中，具体归因仍是开放问题。

更广泛的风险是，存储在平台上的秘密可能在平台之外也有价值。密钥被撤销之前，可能产生费用或提供访问其他系统的权限。无论某起事件最终归因于什么动机，我预计凭据暴露都会继续是严重问题。

我还批评了我所认为的模型拒答问题：它可能让某些合法安全工作更难开展。这是我的经验和判断。服务商是否应限制特定用户或用途，与组织如何保护自身凭据是两个不同的问题。

最后我强调，不能仅因为新闻在相近时间出现，就假设 PHP 漏洞与 Railway、OpenCode 事件有关。及时更新软件，关注相关事件公告，并妥善保护、隔离和轮换 API 密钥，以便暴露时能够迅速撤销。