AI 时代,「一直没出过事」还可信吗?

最近几周内，安全事件目不暇接。

Linux 内核被研究团队演示了远程取得最高权限的攻击，PHP 紧急修复严重漏洞。Railway、Zeabur 等平台接连披露入侵事件，群晖也提醒用户，仍有旧版 NAS 正遭勒索攻击。

操作系统处理网络请求，PHP 运行网站，部署平台保管凭据，NAS 存放文件，证书机构证明网站身份。我们打开一个网站、部署一个应用，背后往往同时依赖其中好几层。换云厂商或把数据搬回家，都绕不开底层软件和设备的维护。

这些事件里确实有低级错误。印度证书机构 eMudhra 的八把中间 CA 私钥都小于 256，一把甚至就是 4，传统脚本就能枚举。Linux 和 PHP 的研究则涉及复杂的内存行为，需要判断外部请求如何触发问题，再把多个步骤接起来。“厂商都是草台班子”解释不了这部分变化：有人开始借助 AI，完成过去需要长期投入的研究。

一些系统过去没出事，受益于攻击者还没花时间读懂它。如今，读源码、查历史修改、整理权限、写程序验证猜测，都有 AI 可以帮忙。

曾经因为难以利用而搁置的问题，可能被重新研究；原本需要熟悉多种技术的人共同完成的工作，也可能由一个研究者带着模型推进。

目前的材料包括受控环境中的研究演示、真实入侵，以及厂商对 AI 使用情况的初步归因，需要分别看。我们已经能确认的是，AI 正在参与理解系统和验证漏洞。相应的修复、发布、升级工作，却要经过另外一批人和流程。

10 月 27 日，Anthropic 公开了一组安全研究。其中一条攻击链针对 Linux 内核的网络处理漏洞 CVE-2026-98432：在暴露 Multipath TCP（MPTCP，多路径 TCP）监听服务的目标上，远程发送数据包，就能在没有账号、无需用户操作的情况下以 root（系统最高权限）身份执行命令。公司称研究使用了尚未公开的内部模型；漏洞已在上游修复，并回补到仍受维护的稳定分支。〔1〕

从缺陷走到接管服务器，中间还有几道障碍。研究中的利用先取得内核地址信息，再劫持执行流程。一次尝试没成功，通常只会让连接握手失败，服务器不会因此崩溃，可以继续尝试。报告中的演示花了 48 分钟取得地址信息，随后约 5 分钟执行命令。这个时间属于其测试环境，不能当成攻破任意 Linux 服务器的倒计时。〔1〕

找到一处“可能访问已释放内存”的代码之后，研究者还要确认：外部能否触发，失败能否重试，泄漏的信息能否继续使用。任何一步不成立，都可能让后面的利用无法完成。模型参与的是这整段分析和实验。

Go 安全团队随后提醒，已演示的攻击依赖 MPTCP 监听端口，但底层错误并不限于 MPTCP，其他路径仍需评估。公告还指出，Go 1.24 起 Linux 监听套接字的默认设置可能让开发者在没有主动配置这项功能的情况下使用它；实际是否可达，还取决于内核支持、程序设置和网络环境。团队建议更新内核，逐个程序禁用 MPTCP 只是脆弱的缓解办法。〔2〕

应用团队可能只知道自己开放了一个普通网络服务，并没有专门配置 MPTCP。协议库的默认设置、内核的支持情况、网络是否允许相关连接，共同决定实际暴露的接口。排查时只看应用代码或内核版本，都可能漏掉条件。

10 月 21 日，PHP 紧急发布更新，修复 CVE-2026-109618 和 CVE-2026-109619，外界将这组问题称为 PHP2Shell。在符合利用条件的部署中，攻击者不需要登录，就可能在服务器上执行代码或读取敏感内存。缺陷位于 PHP 引擎，涉及内存耗尽和错误处理；应用自己的代码没有漏洞，也可能受到影响。具体利用路径依赖版本、配置和运行方式，不能把 PHP 的使用率直接当成已被攻破的网站比例。〔3〕

2024 年的审计及后续分析中，研究者就发现了相关内存耗尽问题的迹象，当时未能证明完整利用路径。Calif 的研究者熟悉 PHP 的历史漏洞，带着具体怀疑重新检查，模型参与源码分析，寻找可用于攻击的中断位置。报告明确交代，方向和历史背景由人提供。〔4〕

OpenAI 表示，Calif 在 Patch the Planet 项目中使用 GPT-5.6 Sol 发现了关键缺陷，Wiz 也独立发现并报告了相关问题。修复和版本发布由 PHP 维护者主导，多家团队参与研究、验证和协调。〔5〕

Wiz 的团队把多个缺陷串起来，反复测试，适配不同应用、PHP 版本和内存布局。模型帮助分析失败原因、调整利用方法，也参与检测与补丁验证。研究最终给出了在 WordPress、Drupal、Joomla 部署上的未登录代码执行演示。〔6〕

此前无法证明利用，可能意味着问题影响有限，也可能只是缺少足够的实验。有了辅助分析和调试的工具，维护者需要重新评估那些因“利用路径不明确”而长期搁置的缺陷。

实际攻击仍受部署条件限制。Wiz 在 10 月 27 日的报告中说，其监测数据里已有利用尝试，尚未观察到完整利用成功；有的请求太大，有的没能泄漏内存地址，还有的连续请求未落到同一工作进程。报告同时援引另一位研究者在特定单进程配置蜜罐上的成功证据。蜜罐是用于观察攻击的测试服务。〔7〕把演示用于其他目标，还需要适配版本、配置和运行方式，这些工作并未因为使用 AI 而消失。

一份漏洞公告说明软件可能出错，却未必说明某家公司的服务怎样运行。攻击者还需要知道，入口后面是什么组件，拿到的令牌能访问哪里，哪项功能会调用高权限服务，旧版本为什么保留了一段特殊处理。源码、配置、日志、历史工单和每次试探返回的结果，都可能提供其中一部分。

一位熟悉内核的人，未必熟悉某个云平台的发布系统；会找网页漏洞的人，也未必能分析凭据如何跨服务流转。研究者要先判断下一步去哪看，写验证工具，再根据失败结果排除猜测。学习不熟悉的代码和技术，一直占用着大量研究时间。

AI 可以读代码、解释协议、整理已获得的配置，也可以写小程序验证假设，再根据结果修改。调查中获得的信息还会不断增加：报错可能暴露一个组件，读它的源码后，可以推测某项配置，再通过下一次请求检查推测。研究者和模型都在这个过程中补充对目标的认识，能使用哪些工具、取得哪些反馈，会影响最终结果。

一次安全审查有工期和预算，研究者只能选择部分代码、部分路径深入检查。追查一条线索需要几周时，它可能被排到后面；同样的工作若能在更短时间内完成，就有机会重新进入检查范围。这个成本变化，影响了哪些问题会被发现，并不要求 AI 独立完成所有研究。

这类变化也出现在实际攻击中。AWS 今年二月记录了一名技术能力有限的攻击者，在一个多月里借助商业 AI 服务，入侵超过 55 个国家的 600 多台 FortiGate 设备。入口主要是公开的管理端口、薄弱凭据和单因素认证。对方把内部网络信息和已有凭据交给 AI 分析，遇到复杂目标依然频繁失败。〔8〕模型帮助他处理已经获得的信息，也扩大了能够尝试的目标数量。

Anthropic 九月的报告也记录了使用 Agent 框架进行侦察、工具开发和数据整理的行动，人类负责目标选择、审核和变现。〔9〕脚本和专业工具早就在做其中许多任务。模型可以根据眼前的系统补写工具、解释返回结果，并协助调整下一步，省去一部分查资料和衔接工具的工作。

“此前的安全只是没有足够上下文”，对一部分系统是成立的：代码无人深入研究，旧问题的利用成本很高，多个服务之间的权限关系也没人梳理。AI 正在改变这些条件。有效隔离和权限限制仍会阻断攻击，知道数据库里有什么，也仍须取得读取权限。这里需要重新判断的，是过去有多少风险依赖于对手没空、不会或不愿继续研究。

“一直没出过事”无法区分这些情况，也无法排除已经发生、却没有被日志记录的入侵。没有告警，可以作为一项观察；要评价安全措施，还需要知道检查过哪些路径、做过什么验证。眼前这批新闻也不足以计算整个行业的攻击成功率变化。

厂商掌握内部设计、配置和测试环境，原本比外部研究者更容易组织验证。但这些资料可能分散在不同团队，工具也未必能访问。需要有人把组件、权限和负责人对应起来，提供可用的测试环境。仅仅给团队买一套模型，并不会自动完成这些准备。

负责检查系统的 Agent 自己也需要权限边界。它可能同时接触外部代码、日志和机密。给它读取和测试的能力时，还要约束它能修改哪些资源、能否创建新凭据，避免把安全检查程序变成另一处拥有广泛权限的入口。

进入一个组件后，攻击者会继续寻找凭据和内部服务。构建、部署、备份都可能需要跨服务操作，它们拥有的权限会影响入侵范围。

Zeabur 八月的入侵起点，是一个客户部署的 NextChat 应用。攻击者利用漏洞在容器中执行代码，通过共享集群内部网络访问路由缓存，拿到一枚权限很大的平台令牌。他用令牌读取内部管理服务的配置，找到 AWS 的最高权限密钥，随后接触到平台生产数据库。部分账户信息和项目环境变量被读取。〔10〕

客户应用能够连接存放平台内部信息的服务，那里保存的凭据又足以取得下一处权限。攻击者沿着这些关系扩大访问范围，过程中不一定需要攻破每个服务的程序。

应用运行在各自容器里，并不代表管理权限也被隔开了。平台还要负责发布、读取配置和备份，这些操作经常需要跨越多个客户环境。保护业务运行的隔离措施，必须同时约束管理系统能做什么。否则，用户看见的是各自独立的项目，后台却可能通过少数管理账户连接起来。

Railway 10 月 22 日的初步报告记录了后续过程：攻击者先取得加密机密，后来又拿到进入自动构建与测试（CI）环境的凭据，解密了包含其他 API 访问权限的构建文件，最终利用被盗凭据的组合解密部分环境变量。这些变量是应用运行时读取的配置，里面可能放着数据库密码和模型 API 密钥。公司初步估计，最多 1.85% 的工作区、约十万个工作区，可能有部分变量受影响；并非其中每项变量都确认泄漏。〔11〕

“已加密保存”因此要连同解密权限一起看。数据库里只有密文，可以挡住单独复制数据库的攻击；若旁边的构建、部署系统保管着解密所需的权限，攻击者还会寻找进入这些系统的办法。平台需要让应用正常取得机密，也需要限制谁能借用这套流程。

Railway 判断，对方意在盗取 AI 服务密钥，通过大量调用为模型蒸馏取得数据，并称初步证据指向使用了削弱安全限制的模型和大量算力。具体利用细节仍未公开，AI 的参与方式目前主要由厂商初步取证陈述支持，尚未得到同等详细的外部验证。〔11〕

API 密钥已经让这类平台成为有直接经济价值的目标。10 月 6 日的 Fireworks 事件涉及评测任务中的环境变量；Lightning AI 10 月 15 日发现凭据遭未授权访问后限制了平台访问，到 28 日先恢复 Drive 的命令行只读访问。两家公司都要求受影响客户处理连接第三方服务的凭据。〔12、13〕

10 月 30 日，Northflank 又要求客户按环境变量可能已被解密来轮换密钥。其状态页随后确认收到用户报告：存入平台的 AI 密钥遭到未授权使用。要求全量轮换是一项防范措施，不等于每枚密钥都已证实被盗。〔14〕

Wiz 当天汇总了本月九家 AI 开发平台的事件。其跟踪的两组下游凭据滥用中，一组在约 30 小时内产生约 80 万次 Bedrock 调用，另一组在约 13 小时内产生约 170 万次调用；报告还发现转售服务测试过这些密钥。研究并未确认各起入侵、后续盗刷和转售都由同一批人完成。〔15〕

模型密钥连接着现成的服务额度和付款账户，盗取后可以调用或转售。平台集中保存许多客户的密钥，找到一次入口，就有机会触及多个账户。攻击者愿意为目标投入多少研究时间，与预期收益有关。模型服务的额度可以变现，因而增加了这类平台被反复研究的理由；至于每起攻击用了什么工具，仍需分别核实。

PingCAP 的 10.6TB 泄漏说法来自攻击方，列出的材料包括管理数据、日志、工单和源码，并非已经核实的客户业务数据库泄漏量。〔16〕官方确认部分内部系统资料、SQL 编辑器文本、账户及商业信息被复制，同时表示，没有证据显示存储在 TiDB 中的数据受到影响。〔17〕这些内部材料仍可能包含系统结构和客户关系，帮助后续攻击者补充对目标的认识。

攻击者读到一枚令牌之后，还要弄清它由哪个服务使用、能请求哪些操作。对平台而言，这要求安全检查覆盖服务之间的调用和授权。各自独立的应用测试，未必会检查发布系统能否读取所有项目的配置，或者备份账户能否访问生产机密。

eMudhra 的问题并不需要复杂攻击。正常的椭圆曲线私钥应从极大的范围里随机选择，它的八把私钥却都落在不到 256 个数的范围内。Scott Helme 从公开证书复现恢复了这些私钥，其中 EM OV TLS CA - G3C 的值就是 4。〔18〕这样的枚举用传统脚本就能完成。

受影响的 TLS 中间 CA 有权给网站签发证书。持有私钥的人可以伪造证书；如果还能截获连接，而客户端尚未阻止这条证书链，就可能冒充相应网站。这不意味着所有历史 HTTPS 流量都可以被直接解密。

按照厂商的初步解释，2025 年 4 月 30 日的密钥生成流程使用了通过 FIPS 140-2 Level 3 认证的硬件安全模块。脚本在正常密钥之外又生成了一组弱密钥，之后错误地用弱密钥申请了证书。公司还表示，相关体系经过独立审计，根因仍在调查。〔19〕

2025 年六月，外部就发现六份证书吊销列表的签名无效。这种列表用于公布哪些证书已经作废。厂商当时将问题归为密钥配置错误，重新签名后发布，工单后来关闭。〔20〕

今年的调查中，eMudhra 补充解释：当时使用的是原本计划采用的正常密钥，因为验签失败，又改用那组有缺陷的密钥重签。Chrome 根证书团队已在公开工单中追问，为什么发现两组密钥不匹配之后，没有进一步追查证书生成过程。〔21〕

当时的处理恢复了签名验证，却没有查清为什么证书对应另一组密钥。现有记录无法证明工作人员那时已知道私钥极弱，但可以确认，这次异常没有促成弱密钥被发现和撤销。

签名验证确认的是“这份签名是否对应证书中的公钥”，不会自动检查私钥是否容易猜中。硬件认证也有覆盖范围，生成脚本、密钥选择和人工核对仍可能出错。这起事件需要追查的是，异常为什么在恢复功能后就结束处理，以及独立审计是否检查过相应流程。

10 月 29 日，群晖公告确认，攻击者正利用一个在 2024 年 12 月已经修复的漏洞，攻击仍运行旧版 DSM 的设备，加密文件并勒索。公告指向 Synology-SA-24:20。这至少说明，近期出现受害设备，不能直接推断当前系统存在新的零日漏洞。〔22〕

同日发布的 360 样本分析给出了另一条路径：其调查的 C3RB3R 勒索攻击使用 CVE-2026-13639 和 CVE-2026-13684，补丁于今年 9 月 18 日发布。〔23〕群晖对应的 SA-26:13 公告将这两项问题列为严重漏洞，涉及未登录远程攻击者读写文件等风险。〔24〕两份报告的入口归因不同，公开材料尚未解释其中的差异。它们与各批次受害设备之间的对应关系，还需要进一步核实。

PHP2Shell 又是另一件事。群晖 10 月 22 日发布、29 日更新的 SA-26:14，列出了 Calendar、Mail Station 和多个 PHP 套件的修复版本；表格将 Hyper Backup 列为不受影响，并说明系统内置 PHP 没有向外暴露相应攻击面，利用风险很低。PHP 7.3 则因生命周期结束不再提供修复。〔25〕安装了某个组件，与外界能够通过它执行代码，需要逐项对照。也不能把前述勒索事件一概归因为 PHP2Shell。

上游修复 PHP 以后，设备商要判断哪些套件受影响，为不同 DSM 分支打包，用户再安装或迁移。系统更新和套件更新需要分别核对。某个分支不再提供修复时，用户还需要更换软件或运行环境，更新按钮已经无法解决问题。

目前没有足够证据确认这轮勒索攻击借助了 AI。360 提到的 AI 用于防守方分析样本，并非对攻击工具的确认。

NAS 的硬盘由用户保管，系统和套件的更新仍依赖厂商，安装更新、设置远程访问和验证恢复则有一部分需要用户完成。长期无人维护的设备，会在漏洞公开、补丁发布之后继续运行旧代码。最新一轮漏洞研究与早已存在的未更新设备，会同时影响安全。

按 Zeabur 十月报告所用的 UTC 时间，10 月 15 日，平台在 15:40 换上新密钥；16:00 的定时备份又收录了它。攻击者此前已经读取备份访问密钥，20:30 使用了换上去的新密钥。新密钥进入备份和之后遭使用都已确认，经由该备份取得它的路径属于研判。〔26〕

依据 Zeabur 初步报告整理，时间为 UTC；虚线部分为研判路径。

新密钥再次进入了原有的备份流程。攻击者若保留读取备份的权限，就可能重新取得它。处置中需要查清哪些系统能够读取、复制和签发凭据，撤销相应访问，再安排替换。仅仅修改密钥值，无法撤销复制或领取它的能力。

Google 披露过一条从开发工具供应链进入云账户的攻击链：攻击者取得 GitHub 访问权，利用自动部署与云平台之间的身份信任获得临时凭据，随后凭过大的部署权限创建管理员角色。〔27〕临时凭据能减少长期遗留的风险；但有权申请它、创建新角色的系统被控制后，攻击者可以在有效期内继续取得权限。

eMudhra 的处置则发生在另一端。私钥公开之后，机构无法收回别人已经复制走的数字，保护依赖客户端停止信任这些证书。Google 很快下发了屏蔽规则，又安排移除相关根证书，并说明证书透明度检查对部分客户端提供了保护。其他软件是否收到更新，取决于各自的分发机制。〔28〕

更换和吊销都需要在使用端验证。旧容器、长期未更新的设备、独立维护证书列表的程序，可能仍接受已经被宣布作废的凭据。还要检查攻击者是否能继续取得替代凭据，避免只处理已经知道的那一个值。

Railway 处置期间暂停了构建和部署，客户更换凭据后，也无法按正常流程发布新值。10 月 23 日 22:06 UTC，原事故状态记录标为已解决，构建、部署、API 和控制台恢复正常；后续恢复工作仍单独跟踪，所查状态页最后一条 10 月 29 日更新仍称暂停新用户注册。〔29、30〕客户还需要检查 AWS、GCP 等外部账户的操作记录和账单。〔31、32〕控制平台入侵和让客户的新凭据生效，依赖同一套发布系统，处置顺序会影响恢复时间。

软银旗下 IDC Frontier 运营的 IDCF Cloud 遭到勒索软件攻击，影响东日本 Region 1 的四个可用区，涉及 495 家企业和自治体。公司最初表示，在原环境恢复困难，客户需要依靠备份重建。〔33〕10 月 14 日确认 194 家客户的备份可以取出；27 日的第七次报告将数字更新为 206 家。〔34、35〕不能把这起事件概括成整个 region 的全部数据永久消失，也不能把确认能够取出备份理解为所有业务已经恢复。

第七次报告还披露，攻击者从门户认证系统所用开源软件的漏洞进入，经管理控制台取得虚拟化基础设施的管理权限，停止并加密客户虚拟服务器。公司调查未发现虚拟服务器内的数据被带出；门户仍在重建和分阶段恢复。〔35〕目前没有公开证据把入口漏洞与 PHP2Shell 联系起来，也没有足够材料确认这次攻击使用了 AI。

客户即使知道有快照，也要等平台确认能否取出、如何交付。快照文件保存在某处，还不等于客户可以在需要时独立恢复业务，操作可能仍依赖已经停用的平台工具。

如果生产系统和所有备份都由同一组管理凭据控制，账户失窃时它们可能同时受影响，管理系统停用时也可能一起失去访问能力。备份存放在不同地区，可以应对一部分物理故障；还需要另外检查权限是否隔离，以及谁能在原账户失效时取得数据。

数据取出以后，还要准备运行环境。导出的数据库可能不包含对象存储中的文件，定时任务依赖的配置可能只留在平台里，解密备份所需的密钥也可能尚未取出。平台正常时实际恢复一次，可以提前发现这些缺项，也能测出处理它们需要多久。

事故期间，还要检查恢复材料是否带回旧凭据或攻击者留下的配置。Zeabur 报告已经表明备份可能携带有效机密，直接把旧环境搬回来，不能当作完成了安全处置。能否重新运行、是否还保留攻击者的访问办法，需要分别验证。

PostgreSQL 提交者 Robert Haas 十月在一篇文章中解释，19 版发布延期与 LLM 找出的大量问题有关。维护者既要处理新版本，也要修补旧分支的安全问题和普通错误，留给新功能审查的时间受到挤压。模型可以起草补丁，正确性、设计取舍和项目规范仍需要人审核。Haas 将延期视为团队优先保证质量的结果。〔36〕

Linux 的压力还包括重复工作。早在 5 月 17 日的发布邮件中，Linus Torvalds 就抱怨，多个人用相似 AI 工具找到相同问题，重复发往私有安全列表，维护者不得不转发、去重，或解释问题早已修复。他要求提交者理解报告，并补上修复等实际工作。〔37〕AI 产生的报告中既有真实发现，也有重复和待核实的内容，维护者都需要花时间处理。

PHP 基金会也解释了修复为什么拖延。团队曾尝试修复内存耗尽问题，但方案分别涉及兼容性、性能、拒绝服务风险或扩展改动；利用路径不明确，熟悉引擎的人手又有限，工作多次停滞。基金会承认决策过程和资源不足造成了结构性失败。它还记录了披露前消息泄漏等情况，最终更新比计划提前一天发布。〔38〕选择修复方案，还要有人承担取舍，并验证对现有软件的影响。

报告要在对应环境中验证，补丁要检查兼容性，发布之后还要交付给设备商和用户。AI 可以协助这些工作，速度取决于测试环境、审核人员和发布安排。增加发现数量时，接收报告和交付更新的能力也需要增加，否则已经确认的问题仍会排队等待。

攻击者只需在目标上找到一条可行路径，维护者则需要照顾公开支持的多种配置，还要处理修复本身引出的新问题。AI 缩短发现时间之后，审查、发布和实际升级所占的时间，可能决定一个漏洞还会暴露多久。

Zeabur 的停运公告谈到了 AI 带来的部署需求，以及持续调整架构积累的复杂度和维护成本。服务会从 12 月 1 日起陆续停止，所有独立服务器和共享集群最迟于 12 月 31 日关闭。两次安全事件是其决策背景的一部分，公告并没有把原因只归为一次入侵。〔39〕

发布新功能有明确交付物，清点权限、核对旧套件、演练恢复却容易被推迟。漏洞发现增加之后，这些工作会以修复、停机和客户支持的形式集中出现。如果团队只增加扫描工具，没有增加确认报告和交付更新的能力，处理时间仍会被拉长。Zeabur 的停运也提示，复杂系统的持续维护是一项实际经营成本。

一次上线前检查有明确范围，无法覆盖此后所有变化。新的研究方法可能发现旧代码里的问题，一个漏洞可能提示研究者检查邻近实现。新功能、迁移和临时排障也会改变平台权限。检查需要随着这些变化继续进行，保留每次覆盖了什么、验证了什么的记录。

购买云服务时，用户看不到内部账户权限；购买 NAS 时，很难检查每个套件的依赖；依赖证书机构时，更不会参与密钥生成流程。用户只能通过认证、公告和维护记录了解其中一部分情况。供应商公开检查范围、已知问题和修复状态，可以减少这种信息差；仅说明“没有发现异常”，留下的疑问仍然很多。

Red Hat 六月发表过一次针对 Fragnesia 的 OpenShift 测试：内核包含缺陷，但测试中的用户命名空间和 SELinux 限制使利用链无法走完。〔40〕结果只适用于其测试配置，但提供了一种可用的检查方式：在组件存在漏洞时，验证其他限制能否阻断后续操作。防守方不必等到每个组件都没有缺陷，再判断整个系统的风险。

这类验证可以纳入日常维护：在受控环境中模拟一个应用失陷，检查它能接触多少管理资源；撤销测试凭据后，检查所有使用端是否拒绝它；核对设备实际运行的系统和套件，确认修复已经生效。保留复现条件和验证结果，下一份漏洞报告到来时，就有记录可供对照。

恢复演练还要假设原控制台不可用，检查数据、解密密钥和运行配置能否独立取得。维护团队处理这些工作，需要时间和预算。PHP 基金会向依赖它的企业请求支持，也是在为确认报告、审核补丁和发布版本争取资源。〔38〕

1. Anthropic：Discovering and exploiting vulnerabilities in critical, real-world software with Claude，2026 年 10 月 27 日。Linux 部分为研究团队演示，所用模型尚未公开。https://www.anthropic.com/research/discovering-vulnerabilities-with-claude

2. Go Security Team：[security] Protecting against CVE-2026-98432，2026 年 10 月 29 日。原始公告说明 MPTCP 利用条件、Go 默认设置和缓解措施的限制。https://groups.google.com/g/golang-announce/c/PCoQcdxoScw/m/aD-MgXEvAAAJ

3. PHP：Security advisory: Critical remote code execution vulnerabilities, update now，2026 年 10 月 21 日。https://www.php.net/archive/2026.php#2026-10-21-5

4. Calif Research：A tale of two PHP remote vulnerabilities（PHP2Shell 研究报告），2026 年 10 月。https://calif.io/php2shell/

5. OpenAI：Patch the Planet: global response coordination as agents uncover critical vulnerabilities，2026 年 10 月 21 日。https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/

6. Wiz Research：PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet，2026 年 10 月 21 日。标题中的比例不代表已遭利用或确认暴露的网站比例。https://www.wiz.io/blog/php2shell-php-rce

7. Wiz Research：PHP2Shell: Exploitation Attempts and Remediation Trends，2026 年 10 月 27 日。其遥测范围的失败尝试与外部特定配置蜜罐的成功证据需分别理解。https://www.wiz.io/blog/php2shell-exploitation-so-far

8. AWS：AI-augmented threat actor accesses FortiGate devices at scale，2026 年 2 月 20 日。https://aws.amazon.com/blogs/security/ai-augmented-threat-actor-accesses-fortigate-devices-at-scale/

9. Anthropic：Detecting and countering misuse of AI: September 2026，2026 年 9 月 10 日。https://www.anthropic.com/threat-intelligence-report-september-2026?page=1

10. Zeabur：Zeabur August 2026 security incident，2026 年 9 月 7 日。https://dash-new.zeabur.com/blogs/august-2026-security-incident

11. Railway：Preliminary Report: Oct 21st Security Incident，2026 年 10 月 22 日发布，含 26 日补充。攻击归因及受影响范围为初步调查结果。https://blog.railway.com/p/preliminary-report-october-security-incident

12. Fireworks AI：Fireworks October 2026 security incident，最后更新于 2026 年 10 月 10 日。https://fireworks.ai/security/bulletins/october-2026-security-incident

13. Lightning AI：October 2026 Security Incident，含 10 月 28 日恢复 Drive 只读访问的更新。https://lightning.ai/blog/oct-2026-incident

14. Northflank：安全事件状态记录，2026 年 10 月 30 日至 31 日持续更新。https://status.northflank.com/

15. Wiz Research：“Black October” for AI Developer Platforms，2026 年 10 月 30 日。包含多家平台披露的汇总和下游凭据滥用分析；研究未将所有入侵和转售活动归于同一主体。https://www.wiz.io/blog/black-october-for-ai-developer-platforms

16. FulcrumSec：The PingCAP TiDB Cloud Leaks。此项为攻击方声明，不代表其中主张均已得到独立核实。https://fulcrumsec.vg/pingcap/

17. PingCAP：October 2026 Security Incident Report: Unauthorized Access to PingCAP Cloud Resources，2026 年 10 月 19 日。https://www.pingcap.com/trust-hub/security/security-update-october-2026/

18. Scott Helme：Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds，2026 年 10 月 20 日。https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

19. eMudhra：Statement on distrust of select Global TLS Intermediate and one Root CA，2026 年 10 月 21 日。文中生成流程及审计说法来自厂商声明。https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

20. Mozilla Bugzilla 1970728：eMudhra: Invalid CRL signatures，2025 年事故记录。https://bugzilla.mozilla.org/show_bug.cgi?id=1970728

21. Mozilla Bugzilla 2083449：eMudhra: Private key compromise of Intermediate Certificates，持续更新。参见第 5、11、30 条评论；其中包括 Mozilla 调查、厂商答复和 Chrome 根证书团队的问题。https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

22. Synology：Synology urges users to update DSM following ransomware attacks on outdated DSM versions，2026 年 10 月 29 日。https://www.synology.com/en-global/company/news/article/C3RB3R/Synology%20Urges%20Users%20to%20Update%20DSM%20Following%20Ransomware%20Attacks%20on%20Outdated%20DSM%20Versions

23. 360：Cerber 勒索攻击群晖 NAS 事件预警，2026 年 10 月 29 日。样本入口归因与群晖同日公告存在差异，正文分别列明。https://360.cn/n/13055.html

24. Synology：Synology-SA-26:13 DSM，2026 年 9 月 18 日。https://www.synology.com/en-global/security/advisory/Synology_SA_26_13

25. Synology：Synology-SA-26:14 PHP2Shell，2026 年 10 月 22 日发布，29 日更新。以受影响产品表格为准，不能将摘要列举的全部套件视为受影响。https://www.synology.com/en-global/security/advisory/Synology_SA_26_14

26. Zeabur：2026 年十月安全事件（初步报告），2026 年 10 月 19 日。https://zeabur.com/zh-CN/blogs/october-2026-security-incident

27. Google Cloud：Cloud Threat Horizons Report H1 2026。参见 From CI/CD to cloud compromise: Real-world breach using OpenID Connect abuse。https://cloud.google.com/security/report/resources/cloud-threat-horizons-report-h1-2026

28. Google：Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates，2026 年 10 月 20 日。https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

29. Railway：Railway Platform Outage 事故状态记录，持续更新。https://status.railway.com/incident/QH8L8B3E

30. Railway：服务状态及 October 21 Incident 后续恢复记录。本次查阅到的最后恢复更新为 2026 年 10 月 29 日。https://status.railway.com/

31. Railway：Security Disclosure Recommendation: Check for Anomalous AWS Access，2026 年 10 月 22 日。https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-aws-access

32. Railway：Security Disclosure Recommendation: Check for Anomalous GCP Access，2026 年 10 月 22 日。https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-gcp-access

33. IDC Frontier：关于部分系统遭非法访问导致故障的第三次公告，2026 年 10 月 8 日。https://www.idcf.jp/news/topics/20261008001/

34. IDC Frontier：关于非法访问故障调查进展的第五次公告，2026 年 10 月 14 日。https://www.idcf.jp/news/topics/20261014001

35. IDC Frontier：关于非法访问调查结果及今后应对的第七次公告，2026 年 10 月 27 日。https://www.idcf.jp/news/topics/20261027001

36. Robert Haas：Postgres 19 is late, and it's AI's fault。Neon 原文 2026 年 10 月 21 日，作者博客于 30 日转载。文中涉及发布延期和错误修复，不能一概视为安全漏洞。https://neon.com/blog/postgres-19-is-late-and-its-ais-faulthttps://rhaas.blogspot.com/2026/10/postgres-19-is-late-and-its-ais-fault.html

37. Linus Torvalds：Linux 7.1-rc4 发布邮件，2026 年 5 月 17 日。关于 AI 报告重复、分流和维护负担的原始陈述。https://lkml.iu.edu/hypermail/linux/kernel/2605.2/01597.html

38. PHP Foundation：Today's PHP Security Release, and How We're Strengthening PHP Security，2026 年 10 月 21 日。包含历史发现、修复取舍和协调披露经过。https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

39. Zeabur：停止运营公告及服务迁移安排，2026 年 10 月 17 日。https://zeabur.com/zh-CN/blogs/zeabur-is-shutting-down

40. Red Hat：Fragnesia and friends: When page cache vulnerabilities keep coming back，2026 年 6 月 2 日。厂商在指定 OpenShift 环境中的测试，不代表所有部署条件。https://www.redhat.com/en/blog/fragnesia-and-friends-when-page-cache-vulnerabilities-keep-coming-back