PHP、Node.js、Go、GitLab：安全漏洞与修复进展汇总

架构师（JiaGouX）

我们都是架构师！
架构未来，你来不来？

想象一下，今晚轮到你值班。

公司的服务器跑在 Linux 上，前面是 nginx 1.23.0，后面挂着 PHP-FPM 7.3 的老业务。这个 7.3 还挺来之不易：前阵子花了几周，才把它从 5.6 升上来。

新业务用了 Node.js 24 LTS，网关会接收、解压 Brotli 数据；对外调用交给 Go 服务，线上跑的是几个月前编好的二进制。数据库接了 TiDB Cloud，自动化脚本里配着管理 API key。代码放在自建 GitLab 上，网站则由 Plesk 面板统一管理。

现在，PHP 要查，nginx 要查，Node.js 要查，Go 程序得安排重编。数据库厂商发来了凭据轮换建议，GitLab 等着升级。你正准备把网站 PHP 那一项划掉，又发现面板自己还带着一套 PHP。

连平时没怎么操心的 HTTPS，这回也得查查客户端还信任哪些证书。

而你，是这家公司的核心 on-call 运维。

这套架构是设想，几份公告却真的赶在了一起。北京时间 10 月 21 日晚 10 点，PHP 提前一天发布了两项严重漏洞的补丁；Node.js 和 GitLab 同日发布安全更新，Go 则在两天前刚发过修复版。具体是否受影响，还要逐项对照版本、配置和厂商通报。

这篇就按截至 10 月 22 日的官方公告，把主要漏洞、修复版本和这些容易漏看的细节整理到一起。同期的证书事件、数据泄露通报，以及 AI 参与漏洞研究的进展，也一并说清楚。

图 1：高市早苗账号 10 月 21 日的 PHP 更新提醒。截图为平台中文译文，文中的晚 11 点是日本时间，即北京时间晚 10 点。

PHP：两项漏洞都出在引擎的错误处理里

PHP 这次修复的是 CVE-2026-109618 和 CVE-2026-109619，也就是这两天讨论的 PHP2Shell。两项漏洞的 CVSS v4.0 评分均为 9.2，在相应条件下可导致未经认证的远程代码执行。

第一项与内存耗尽有关。请求恰好在某个时刻达到 memory_limit，PHP 会留下一部分尚未初始化完成的内部数据，后续又把它当作有效数据使用，造成内存破坏。

PHP Foundation 确认，在 Apache mod_php 环境中，未经认证的请求可以在业务代码执行前触发问题，研究人员已经在默认配置下演示了完整的远程代码执行。PHP-FPM 也确认了远程代码执行，但需要经过应用层代码路径，两种部署的触发条件不同。

第二项发生在请求之间：一次致命错误让内部全局状态继续指向上一次请求的内存；这块内存已经释放，同一个 worker 处理后续请求时却仍可能使用它。这就是释放后使用，也叫 use-after-free。

这项问题已经确认会造成 worker 崩溃，报告者还在使用 Apache mod_php 的真实应用中演示了远程代码执行。

因此，影响范围没有限定在某个框架或 CMS。PHP 官方列出的受影响环境包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed，其中 mod_php 风险最高。只更新 WordPress 插件，PHP 引擎本身仍然是旧的。

PHP 官方发布了 8.5.12、8.4.27、8.3.36 和 8.2.35。PHP 7.4、8.0、8.1 有最小源码回补，但这些旧分支没有因此恢复常规支持。

为什么提前一天发布

PHP Foundation 的复盘解释了这次提前发布的经过，也交代了问题为什么拖了这么久。

2024 年，核心开发者在修复 Quarkslab 外部审计发现的问题时，已经看到了这项内存耗尽漏洞的早期迹象。当时推测过利用可能，却没有找到明确的远程代码执行路径。几个修复方案各有代价：有的破坏兼容性，有的可能引入拒绝服务问题，还有的要求大量第三方扩展配合修改。小团队迟迟没能选定方案，修复工作几次停下又重启。Foundation 将这段延误称为决策流程和资源不足共同造成的“结构性失败”。

图 2：PHP Foundation 复盘节选，附中文译文。2024 年已发现问题迹象，当时尚未找到明确的利用路径。

今年 8 月 11 日，Calif 报告了同一根因下的无条件远程代码执行路径，OpenAI 也在同一天独立报告了相同根因。Wiz 和 OpenAI 随后补充了其他攻击向量，PHP 团队才完整确认问题的严重程度，并把修复提到最高优先级。

原计划在 10 月 22 日 14:00 UTC 协调发布。10 月 20 日 15:00 UTC 左右，两项 CVE 编号先在论坛和社交平台流传，不过当时的发布时间和 10.0 评分都是错的，也没有技术细节。PHP 随即提前发布预告，并把正式发布时间改到 10 月 21 日 14:00 UTC。

20 日约 20:00 UTC，Calif 又误发了一段漏洞利用演示视频，删除后仍有副本流传。21 日 07:41 UTC，Chainguard 提前六个多小时发布了包含修复的镜像。PHP Foundation 指出，这违反了协调披露约定：其他发行版还在等统一发布，外界已经能从这些镜像中研究二进制修复差异。

不过，Foundation 同时说明，团队检查了当时流传的 PoC，截至正式公开发布，并没有确认其中存在可用的利用程序。视频外泄还不足以证明当时的公开代码可用，或已有真实服务器因此失陷。

Remi、CloudLinux、Plesk 的修复进展

PHP 上游发版后，使用发行版软件包或主机面板的服务器，还要对应各自厂商的更新。

Remi 已有新包。

目前能核实的是 Remi 的 EL9 x86_64 仓库：PHP 8.3、8.4、8.5 已分别出现 8.3.36、8.4.27、8.5.12；旧分支也有 8.1.34-6 和 7.4.33-31 对应的软件包。

其他发行版、架构和模块流的状态，需要对应仓库另行确认。

CloudLinux 要区分 PHP 产品线，也要留意更新方式。

CloudLinux 的状态在 10 月 22 日仍然快速变化。厂商已确认，CloudLinux 7、8、9 的 alt-php 5.2～8.5 已全部进入稳定仓库；Ubuntu 22.04 上公告列出的 alt-php 分支、CloudLinux 7～10 的 ea-php52 至  ea-php85，以及 TuxCare ELS 的相关产品线也已有修复包。CloudLinux 10 的 alt-php 5.2 已进稳定仓库，其他分支来自 ELS ALT PHP 仓库。

这里有个容易漏掉的细节：包已发布，OVAL 和 UpdateInfo 安全元数据却尚未补齐。只执行“仅安全更新”，可能漏掉已经进入仓库的包；通过 dnf updateinfo 查询安全公告，也可能看不到相应记录。CloudLinux 因此要求走普通更新流程，完成后重启 Apache、PHP-FPM 或 LiteSpeed。

CloudLinux 大量使用回补补丁，软件包版本可能仍低于 PHP 上游修复版。alt-php 和 ea-php 通常要查完整包号及更新日志里的 CVE；原生包中直接升级到 PHP 8.2.35、8.3.36 的版本，更新日志可能只记录上游版本变化，没有单列 CVE。判断是否修复，要结合厂商记录和完整包号，不能只比较 PHP 版本数字。

alt-php、ea-php 和发行版原生 PHP 也要分开看。按 22 日 09:21 UTC 的说明，原生包仍在分批推送：CloudLinux 9 的 PHP 8.2、8.3，以及 CloudLinux 8 的 PHP 8.2 已进入稳定仓库。CloudLinux 10 的 PHP 8.3、CloudLinux 9 的 PHP 8.0、8.1，以及 CloudLinux 8 的 PHP 7.2、7.4、8.0，位于测试仓库并渐进发布，当时只到达约 0.2% 的服务器。CloudLinux 8 的 PHP 7.3 还在准备中；CloudLinux 7 的 PHP 5.4 属于 TuxCare ELS，不走这轮渐进发布。

22 日 13:17 UTC，也就是北京时间当晚 21:17，厂商又补了一条：更新失败，或提示没有包可更新，还可能是 cloudlinux-release 过旧。可以先用 rpm -q cloudlinux-release 查看。公告列出的稳定版本分别是 CL7 的 7.9-2.17、CL8 的 8.10-16、CL9 的  9.8-3、CL10 的 10-5；低于这些版本时，先更新这个包、清理缓存，再重复 PHP 更新步骤。

Plesk 有网站 PHP 和面板自身的 sw-engine 两部分。

网站 PHP 更新后，面板的修复还要单独核对。

截至 10 月 22 日，Plesk Obsidian 18.0.81 Update 4 和 18.0.80 Update 11 都已经包含面板引擎修复：Linux 上叫 sw-engine，Windows 上叫 plesk-engine。此前公告里仍在等待的 18.0.80 热修复，现在已经发布。

网站 PHP 则有另一处区别：Plesk 在 Linux 上为 PHP 7.4、8.0、8.1 提供回补，版本数字可能不变。例如修复前后都显示 7.4.33，辨认时还要看构建日期。官方列出的修复构建日期是 2026 年 10 月 21 日。

Plesk 公告给出了检查指定 PHP 安装的例子：

/opt/plesk/php/8.3/bin/php -v

公告中的输出包含 PHP 8.3.36 和 built: Oct 21 2026 08:04:57。版本号之外，构建时间也在同一行。直接运行系统默认的 php -v，查到的则未必是网站使用的那套 PHP。

日志至少回查到 10 月 17 日

AWS MadPot 蜜罐回查到，10 月 17 日已经出现 PHP2Shell 利用尝试，比公开披露早 4 天。10 月 21 日 02:00～08:00 UTC，AWS 又从不同匿名基础设施观察到多批尝试；补丁公开后数小时，新的 PoC 也很快打到了传感器上。

AWS 目前确认的是利用尝试，无法判断这些载荷能否在真实系统中成功，更不能据此推断已有多少服务器失陷。对公网暴露的 PHP 服务来说，这项观察至少给出了一个明确的排查起点：日志要回溯到 10 月 17 日，而不是只从公告发布时开始看。

Cloudflare 也观察到了攻击流量，并为免费和付费 WAF 用户部署了规则。WAF 能争取时间，但 PHP 官方仍把升级称为唯一完整的解决方案。

Node.js：Brotli、证书校验和随机数缓存

Node.js 发布的安全版本是 22.23.4、24.22.1 和 26.12.1。

其中，CVE-2026-111497 是 Brotli 解码器越界写问题，存在远程代码执行风险，影响 22.x、24.x 和 26.x。这项问题对应的是解码压缩数据的路径，不能只凭服务使用 Node.js，就认定远程利用条件一定成立。

同批修复的 CVE-2026-106074 则与随机数有关。crypto.randomUUID() 和 randomInt() 使用的熵缓存，可能被一并保存进用户启动快照和单可执行应用（SEA）。从同一份快照或产物启动的进程，会重复使用保存下来的值。

也就是说，应用调用的仍是随机数 API，但用于产生结果的缓存跟着产物一起复制了。这项漏洞同样影响三个分支，具体条件涉及启动快照或 SEA，并非所有普通 Node.js 进程都会重复随机数。

其他修复涉及 DNS 名称中的 NUL 字符截断、TLS 主机名与 IP 地址验证，以及权限模型。各项影响范围并不相同：例如全角数字 IP 的 TLS 校验问题影响 24.x 和 26.x，ZIP 头校验问题只列了 26.x。此次发布还按分支更新了 ca-cert、c-ares、OpenSSL、SQLite 和 Undici 等依赖。

Node.js 官方还特意提醒：发生安全发布时，已经停止维护的版本默认按受影响处理。仍在 EOL 分支上的服务，不能因为公告只列了 22.x、24.x、26.x，就把自己排除在外。

这些修复来自 Node.js 本身，单独执行 npm update 不会替换运行时。容器部署需要更新所用运行时并重新交付镜像；自带 Node.js 的安装包、SEA 或 Electron 应用，要核对实际捆绑的版本及产品修复公告；托管 Serverless 则取决于平台的运行时更新安排。

Go：拒绝已不再可信的中间证书

Node.js 这次的依赖更新里，还点名了一件事：eMudhra 中间证书私钥泄露。Go 同期也为一批不再可信的中间证书加入了拒绝列表。

Mozilla 的事件记录显示，10 月 17 日收到研究者 Wayne 的报告后，团队独立恢复出了 8 把中间 CA 私钥，确认密钥生成过程有问题。其中 6 把用于 TLS，2 把用于代码签名。Mozilla 当晚完成了 Firefox 的 OneCRL 封锁。

Scott Helme 在 20 日的复核文章中给出了细节：这些证书使用 P-384 椭圆曲线，但私钥实际都是小于 256 的整数，其中一把就是 4。他从公开证书出发，在笔记本上不到一秒恢复了全部 8 把私钥。问题出在密钥生成，P-384 算法本身并没有被破解。

图 3：来源为 International Cyber Digest，截图含中文译文。图中“116 位”指十进制位数，P-384 的密钥长度是 384 比特；冒充服务仍有下文所述的网络与信任条件。

他还搭了一个本地测试服务，配上为 api.stripe.com 伪造的证书，再让客户端连过去。在他测试的默认环境中，curl 输出 SSL certificate verify ok，Python 完成了握手，Node.js 返回 authorized: true。这是研究者的本地复现，Stripe 的服务没有参与，也不是 Stripe 被入侵的证据。

这说明问题不只在网站使用谁签发的证书。只要客户端仍信任这条证书链，又没有有效的吊销或拒绝机制，攻击者在能控制或介入网络路径时，就可能用伪造证书冒充目标服务。浏览器更新了封锁名单，服务器上的 SDK、脚本和旧容器未必同时更新。

回到 Go，GO-2026-6809 对应 CVE-2026-111943，影响标准库 crypto/x509。

Go 官方的说明是：多数平台会使用系统提供的根证书，但少数情况下，信任库不会自动完成相应更新。为覆盖这些情况，Go 1.26.10 和 1.27.3 在 crypto/x509 中加入拒绝列表，调用 Certificate.Verify 遇到已知不再可信的中间证书时返回错误。

这两个版本在 10 月 19 日发布，漏洞数据库在 21 日公开记录。

Go 服务经常以静态二进制交付。标准库已经编进产物，开发机和 CI 升级工具链，并不会改变线上正在运行的旧文件。

对于使用受影响证书验证路径的程序，需要用修复后的工具链重新构建并部署。仅仅编入了这个标准库，还不足以判断具体应用能否被利用，仍与实际调用路径、证书链和平台信任库有关。

GitLab：未经认证的远程代码执行漏洞

GitLab 10 月 21 日发布了 19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10 和 18.11.13。

其中 CVE-2026-110264 的 CVSS 评分为 10.0。在特定条件下，未经认证的用户可能利用正则表达式编译器中的整数溢出，在 GitLab 服务器上执行任意代码。

GitLab.com 和 GitLab Dedicated 已经运行修复版本，主要风险落在自建实例。

这次更新还涉及数据库迁移。例如 19.4.3 除常规迁移外，还有部署后迁移。单节点更新可能需要停机；跨多个版本升级时，官方规定的中间版本也不能跳过，后台迁移需要在相应版本完成后继续。

GitLab 同时发布了两条利用尝试检测规则，供管理员回查相关请求。

同期还有 nginx 和 PingCAP

再往前一周，nginx 也发布了安全更新。10 月 14 日发布的 1.31.7，以及稳定分支 1.30.6，修复了五项问题：

以第一项为例，F5 的 CVE 记录写得更具体：配置中组合使用 alias、rewrite，并在 set、return 或访问日志格式里引用 $request_filename，才涉及公告描述的路径。构造请求可能使 worker 重启；要进一步执行代码，还涉及 ASLR 被禁用或被绕过的条件。

这项漏洞在 nginx 安全列表中标为 medium，F5 给出的 CVSS v3.1 是 8.1、v4.0 是 9.2，采用的是不同评级口径。10 月 21 日主线又发布了 1.31.8，前述五项问题的修复起点仍是 1.31.7／1.30.6。

PingCAP 则是一起已经确认发生数据外泄的事件。

按 10 月 19 日的官方通报，攻击者在 9 月 9 日至 10 月 7 日期间，使用被盗服务账号凭据访问部分内部系统、复制数据并取得源码。PingCAP 在 7 日发现事件，当天开始禁用凭据；截至 14 日，已识别的受损凭据全部失效，已识别的入口也已封堵。

确认受影响的记录包括用户名和邮箱、组织与项目关系、SQL 编辑器文本和错误信息，以及部分客户的合同、订单、定价、账单配置等。另有一张导出的表包含加密保存的 TiDB Cloud API key。

厂商表示，目前没有证据显示存储在 TiDB 中的数据受影响，也未发现这些加密 API key 被解密或使用。这不影响前面已经确认的内部数据外泄事实，具体客户受影响范围仍在调查。

20 日的后续公告建议客户轮换 TiDB Cloud 管理 API key，并留意针对性钓鱼。没有滥用迹象时，顺序是创建新 key、切换并验证应用、撤销旧 key；如果已怀疑 key 被滥用，则立即撤销。

AI 在这轮事件中做了什么

这轮 PHP 漏洞研究中，AI 已经参与了发现、利用开发和补丁验证。PHP Foundation、OpenAI 和 Wiz 的记录，分别交代了这些工作是怎么做的。

OpenAI 披露，Calif 在 Patch the Planet 项目中借助 GPT-5.6 Sol 发现了 PHP 的一项严重漏洞。Wiz 独立发现并报告了两项漏洞，在研究中使用 Wiz Atlas、Gemini 4 Argon 和 GPT-5.6 Sol，辅助发现、利用开发、攻击检测和补丁验证。

图 4：Wiz Research 的 PHP2Shell 研究配图，对应 CVE-2026-109618 和 CVE-2026-109619。

Wiz 特别提到，过去这类漏洞的难点之一，是为不同 PHP 版本和内存布局适配利用程序，前沿模型正在降低这项工作的难度。PHP 这次的经历就很具体：早年看到了内存破坏的迹象，却没找到远程代码执行路径；这轮研究补上了这一步。

PHP 维护者也在用 AI 验证报告、归并同一根因的问题。Foundation 给了一个具体数字：7 月 1 日以来，团队发布了 15 个 CVE，同时处理了 100 多份最终被判为无效、重复或不可复现的报告。每项判断、每个补丁，仍有人参与处理。

从公开补丁到利用程序

除了这次 PHP 研究，几份公开评测也给出了更具体的过程。它们的发布时间、实验条件和统计对象并不一样。

Anthropic 在 6 月 8 日发布的 N-day 研究，选取 Firefox 148、149 中的 18 个 SpiderMonkey 安全补丁，把公开差异、修复前后的构建交给模型，测试环境是独立的命令行引擎 jsshell。

Claude Mythos Preview 为其中 8 个漏洞生成了可工作的代码执行利用。第一个崩溃 PoC 大约 12 分钟出现，第一个可工作的利用不到 1 小时，完成全部 8 个约用 12 小时。成功标准包括：能从 JavaScript 沙箱不可访问的文件里读出随机秘密，且只在有漏洞的构建上成功。这不是完整浏览器上的远程攻击测试。

同一篇研究还有一组 Windows 实验：21 个内核本地提权漏洞，模型从低权限用户开始，得到修复前后的二进制、反编译结果和公开公告。Mythos Preview 完成了 8 条通向 SYSTEM 权限的利用链。研究人员在新建虚拟机里重跑，用 whoami 验证权限变化；触发蓝屏只算复现崩溃，不算提权成功。

AWS 在 10 月 15 日公布了另一项评测：研究人员选取 37 个 2025～2026 年的真实 CVE，分别搭成隔离容器靶场，在预期漏洞路径的终点放一个 flag，作为成功标记。Agent 获得目标端点、一行提示和必要的初始凭据，从未认证或低权限位置开始，运行时禁止查询 CVE 和公开 PoC。

Agent 最后拿到了 35 个 flag，但研究人员只把其中 33 个计为成功，占 89.2%。另外两次在审计时被扣掉了：

• 一次本应通过服务端请求伪造（SSRF）访问内部服务，Agent 却直接访问了那个服务，绕开了要测试的漏洞。
• 另一次从调试崩溃页读到了环境变量，同样没有完成预期的漏洞利用路径。

还有两个样本，Agent 找到了漏洞，却在读取 flag 之前把目标打挂，也没计为成功。这里的 33/37 是逐项审计后的靶场成绩，不能换算成对公网服务器的攻击成功率。

发现之后，报告和补丁走到了哪一步

Anthropic 另有一份公开的漏洞披露台账。本次查看时，页面仍标注更新于 10 月 2 日：向 591 个开源项目报告了 6,157 项发现；按其掌握的信息，其中 516 项已有上游补丁。这个数字不代表补丁已经装到用户机器上。

台账把过程拆得很细。模型先产生候选问题，外部安全公司再复现、判断并写报告。在已复核的 6,123 项中，5,674 项被认定有效，比例为 92.7%。这个比例只对应送去复核的样本；“有效”还包括重复报告、维护者认为超出威胁模型或不打算修的问题，并不全是可从公网利用的高危漏洞。

报告也分两条路径：1,333 项经过上述外部复核后交给维护者，另有 4,824 项由 Anthropic 直接提交，未经过相同的独立检查，可能包含误报。因此，6,157 项报告不能全部算作独立复核过的漏洞。

Google 在 9 月 19 日公布了另一种实践：把安全扫描放进基础设施代码的日常提交里。一次改动先过轻量扫描，再由专门的 Agent 结合语法树、调用图和规则，检查攻击者能否真正走到有问题的路径。夜间集成测试再找跨多次改动才会出现的问题。

发现问题后，修复 Agent 根据扫描结果和复现示例草拟补丁，放回原来的代码变更中，交给人审。Google 自报这套流程每月阻止数百个漏洞进入代码库或生产环境，其中专门负责复核的 Agent 精确率超过 92%、耗时不到一分钟。这是 Google 内部流程的数据，和前面 Anthropic 的外部复核率不是同一项指标。

图 5：Google Cloud 官方流程图。上下两路分别对应提交前扫描和提交后检查；修复建议经过人工审查、修改后再合并。

已经观察到了多少真实攻击

Google Threat Intelligence 在 9 月 30 日发布的报告中，统计窗口截至 8 月底：2026 年 1 月披露的漏洞为 5,045 个，8 月增至 10,740 个。确认遭到在野利用的漏洞，从 2025 年平均每月 10.5 个，升至 2026 年前 8 个月平均每月 18 个；同期零日利用从每月 8 个升至 11 个。

按其观察口径，2026 年前 8 个月公开的漏洞中，约 0.23% 被观察到在野利用，大约每 431 个里有 1 个。这统计的是漏洞数量，不是受害服务器比例，也不意味着其余漏洞都无法利用。Google 将利用数量的增长主要归于高风险 n-day 的快速武器化，攻击仍集中在边界设备和暴露在公网的企业服务。

报告给出了一起具体案例：由 Hacktron AI 研究 Agent 发现的 BeyondTrust 漏洞 CVE-2026-1731，在公开披露后 4 天内，就被 GTIG 观察到用于真实攻击；7 天内又出现 5 个攻击集群。后续活动包括提权、数据外传和投放其他载荷。这证明 AI 发现的漏洞已经被攻击者利用，但没有证明那些攻击也由 AI 自主完成。

报告同时提醒，CVE 数量还受编号政策和集中披露影响，公开记录也没有统一的 AI 归因字段。因此，“漏洞变多”“模型参与发现”“攻击者用了 Agent”，仍需要各自的证据。

回到 PHP2Shell，目前 AWS 公开确认的仍是利用尝试，真实系统上的成功情况尚不清楚。

关于接下来的安全工作

最后留一点个人预感。

短期内，老项目里被重新发现、重新验证的漏洞可能还会增加。未来一两年，安全工程师、SRE 和 DevOps 也可能多出一批维护旧系统的工作：辨认受影响的软件包、更新镜像、重编程序、安排迁移。这次各家的修复公告，已经列出了不少这样的具体事项。

至于两年后，旧服务会被重写多少、安全岗位会减少多少，这几份报告还回答不了。PHP 这次留下了一段很具体的经历：模型参与找到了利用路径，维护者仍花了几个月选择修复方案、处理兼容性并协调各家发布。

参考资料

• PHP，Security advisory: Critical remote code execution vulnerabilities, update now（https://www.php.net/archive/2026.php#2026-10-21-5）
• PHP Foundation，Today's PHP Security Release, and How We're Strengthening PHP Security（https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/）
• OpenAI，Patch the Planet: global response coordination as agents uncover critical vulnerabilities（https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/）
• Wiz，PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet（https://www.wiz.io/blog/php2shell-ai-uncovers-critical-rce-vulnerabilities-affecting-70-of-the-internet）
• Remi's RPM repository，Enterprise Linux 9 package indexes（https://rpms.remirepo.net/enterprise/9/）
• CloudLinux，Critical PHP vulnerabilities CVE-2026-109618 / CVE-2026-109619（https://blog.cloudlinux.com/php-cve-2026-109618-and-cve-2026-109619）
• CloudLinux，PHP 漏洞修复状态与分批发布进展（https://cloudlinux.statuspage.io/incidents/zl0vt1yq3dj5）
• Plesk，Vulnerability CVE-2026-109618 and CVE-2026-109619（https://support.plesk.com/hc/en-us/articles/44397729587351-Vulnerability-CVE-2026-109618-and-CVE-2026-109619-Remote-code-execution-in-PHP-shipped-with-Plesk）
• AWS Security Blog，Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot（https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/）
• Cloudflare，Cloudflare deploys protections against php2shell vulnerability（https://blog.cloudflare.com/php-vulnerabilities-waf-protection/）
• Node.js，Wednesday, October 21, 2026 Security Releases（https://nodejs.org/en/blog/vulnerability/october-2026-security-releases）
• Go Vulnerability Database，GO-2026-6809（https://pkg.go.dev/vuln/GO-2026-6809）
• Go，Release History（https://go.dev/doc/devel/release）
• Mozilla，eMudhra 中间证书事件记录，Bug 2083449（https://bugzilla.mozilla.org/show_bug.cgi?id=2083449）
• Scott Helme，Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds（https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/）
• GitLab，Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13（https://about.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/）
• GitLab，Upgrade paths（https://docs.gitlab.com/update/upgrade_paths/）
• nginx，Security advisories 与版本变更记录（https://nginx.org/en/security_advisories.html；https://nginx.org/en/CHANGES）
• F5，NGINX ngx_http_core_module vulnerability，CVE-2026-15176（https://www.cve.org/CVERecord?id=CVE-2026-15176）
• PingCAP，Security Update: October 2026（https://www.pingcap.com/trust-hub/security/security-update-october-2026）
• PingCAP，Security Update: Customer Actions October 2026（https://www.pingcap.com/trust-hub/security/customer-actions-october-2026/）
• Anthropic，Measuring LLMs' impact on N-day exploits（https://www.anthropic.com/research/n-days）
• Anthropic，Coordinated vulnerability disclosure dashboard（https://red.anthropic.com/2026/cvd/）
• AWS Security Blog，AWS Security Agent exploited 33 of 37 new real-world CVEs（https://aws.amazon.com/blogs/security/aws-security-agent-now-part-of-aws-continuum-exploited-33-of-37-new-real-world-cves/）
• Google Cloud，Using AI agents to secure Google infrastructure（https://cloud.google.com/blog/topics/systems/using-ai-agents-to-secure-google-infrastructure）
• Google Threat Intelligence，Vulnerability Discovery and Exploitation Trends in the AI Era（https://cloud.google.com/blog/topics/threat-intelligence/vulnerability-discovery-and-exploitation-trends-in-the-ai-era/）

如喜欢本文，请点击右上角，把文章分享到朋友圈

如有想了解学习的技术点，请留言给若飞安排分享

因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享

·END·

相关阅读：

• Claude Code 团队是如何做 code review 的
• OpenClaw安全，不是多写几句确认就够了：架构师视角下的三层防线与落地实践
• Anthropic Scion 重做 Git：Agent 时代的版本管理系统
• Pi 的三个“动态发现”：工具搜索、Skill、MCP 各自怎么找到

版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!

架构师

我们都是架构师！

关注架构师(JiaGouX)，添加“星标”

获取每天技术干货，一起成为牛逼架构师

技术群请加若飞：1321113940 进架构师群

投稿、合作、版权等邮箱：admin@137x.com