【安全速报】10月30日高危漏洞紧急预警

探知安全
探知安全

探知安全

2026年10月30日 10:30
江西

去阅读

【安全速报】10月30日高危漏洞紧急预警

2026年10月30日  |  探知安全

今日焦点

本期最该盯的不是分数，而是补丁时钟、攻击时钟与取证时钟正在彻底脱节。三条线各走各的。第一条最刺眼：Magento 的 PolyShell 漏洞（CVE-2026-48356）补丁 7 月 14 日就发布了，CISA 直到 10 月 27 日才把它收进 KEV——而攻击从 3 月 30 日起就已经在跑，一个\"在野利用了七个月\"的洞，联邦强制截止日才刚下发到 11 月 10 日；Sansec 统计显示，3 月 30 日那一小时内就有 471 家商店被灌入 Web Shell，到 4 月中旬他们监测的商店里超过八成遭遇了针对这个洞的恶意上传。第二条更急：Linux 内核的 Fragnesia（CVE-2026-46300）5 月 13 日就已公开、且带着可直接使用的 Metasploit 模块，10 月 28 日进 KEV，联邦截止日是 10 月 31 日——留给私界的实际窗口不足 24 小时；这条洞最麻烦的地方在于它改的是内存里的页缓存，磁盘上的 /usr/bin/su 纹丝不动，于是重启既是你的修复动作，也是销毁证据的动作。第三条是完全没有补丁可打的一面：EDK II 的 CVE-2026-97631 在固件里躺了 16 年，修复 10 月 15 日合进上游主分支，但没有任何稳定版带着它，Red Hat 把 RHEL 8/9/10 的 edk2 标成受影响且暂无 errata，处置只剩\"关掉网络引导\"。除此之外还有一条值得单独看的攻击链：思科 SD-WAN 控制器上的 KeyDrift 框架（Talos 10 月 28 日披露）能在合法进程内部解密控制面流量、把分支间 IPsec 的 AES-256 密钥材料抽走外传，攻击基础设施与 Volt Typhoon 的 \"Silent Train\" 高度重叠。建议优先排查：所有对外提供 Magento / Adobe Commerce 商店的实例、所有跑 XFRM ESP-in-TCP 的 Linux 主机、所有 PXE 网络引导的服务器，以及所有近期出现过不明重启的 ASA / FTD 网关。

漏洞详情

严重CVE-2026-48356CVSS 9.3

Magento 的 PolyShell：补丁发了三个月才进 KEV，而攻击当天就开始了（CVSS v3.1 9.3·CWE-434·10/27 入 KEV·953 家网店沦陷）

这是本期故事线最完整的一条。Sansec 研究员 Sam Browand 于 2026 年 3 月 17 日公开了这个漏洞并命名为 PolyShell，两天后（3 月 19 日）攻击者就开始利用，3 月 30 日的一次自动化攻击波在一小时内把加载器注入 471 家商店，到 4 月中旬，Sansec 监测范围内超过八成商店都出现了针对该洞的恶意 PHP 上传尝试。技术上它是 CWE-434（危险类型文件的不受限上传）：攻击者无需任何凭据调用 REST 的访客购物车路由 /V1/guest-carts/{cartId}/items，把文件当\"定制商品选项\"上传，Magento 只检查文件头是否是合法图片就写进 pub/media/custom_options/quote/，攻击者发送 GIF/PNG 头 + PHP 代码的 polyglot 文件（文件名通常是 index.php），在 2.0–2.2 时代的 nginx 默认配置、或任何把 media 目录下 .php 交给 FastCGI 的非标准配置下直接执行。Sansec 把后门命名为 accesson.php，散落在 assets/images/ 下的多个子目录，具备回连、基于 eval 的命令执行与继续上传能力。真正的故事还在后面：Sansec 追踪一条自 2025 年 7 月起、至今 15 个月换了五个域名的加载器行动，manulfie.click（863 家）、neswnsssn.click（494 家）、lanhd6549tdhse.top（355 家）、additionalver.com（246 家）、deepveindrilling.com（83 家，10 月 6 日才注册、次日就开始挂马），累计 953 家在线商店中招，绝大多数是 Magento。加载器代码写在 cms_block 表的内容字段里，10 月 23 日那次改写加入了浏览器指纹识别（navigator.webdriver、Selenium 全局变量、ChromeDriver 的 cdc_ 属性、WebGL 显卡名、CPU 核数、内存、屏幕尺寸、时区、语言、client hints），安全扫描器拿到的是 HTTP 200 和一个空页面。有几处口径必须如实说清：Adobe 公告 APSB26-73 给的是 CVSS 3.1 9.6（AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L），而 Adobe 作为 CNA 的 CVE 记录与 NVD 给的是 9.3（同一向量，可用性影响记为 A:N）——差的只是可用性这一项，两个分数都要看；向量里的 UI:R（需要用户交互） 容易被误读成\"得有人点一下\"，但 NVD 描述里受害者只需访问恶意 URL 或与被污染页面交互，而 Sansec 观察到的是完全自动化的大规模攻击波，实际节奏没被这一项拖慢。Adobe 把它评为 Priority 2（30 天内修）而非 Priority 1，公告里那句\"尚未发现任何在野利用\"到 8 月 11 日更新时还留着——而按 EPSS 模型（10 月 27 日刷新），它的可利用性已排在全部 CVE 的第 98 百分位。最扎心的一条：打了补丁的商店照样中招——一家 2.4.7-p10、核心补丁一个不缺的商店在 10 月 23 日 16:46 UTC 被挂上 deepveindrilling.com，而 eComscan 早在 9 月 16 日就发现它有流氓管理员账号、9 月 24 日发现 GSocket 后门。

影响范围

Adobe Commerce：2.4.4（≤2.4.4-p18）、2.4.5（≤2.4.5-p17）、2.4.6（≤2.4.6-p15）、2.4.7（≤2.4.7-p10）、2.4.8（≤2.4.8-p5）、2.4.9；Adobe Commerce B2B：1.3.3、1.3.4、1.4.2、1.5.2、1.5.3；Magento Open Source：2.4.6、2.4.7、2.4.8、2.4.9；Adobe I/O Events：1.6.0 至 1.21.0。修复版本为对应的 -2026-jul 构建（2.4.9-2026-jul、2.4.8-2026-jul、2.4.7-2026-jul、2.4.6-2026-jul 等），Adobe I/O Events 修至 1.21.0。这里有三个必须注意的坑：一是 Adobe 七月的修复是以独立补丁文件（isolated patch）形式发布的，不是 Composer 包，且每个补丁只适用于该分支的最高补丁级别（2.4.8-p5、2.4.7-p10、2.4.6-p15、2.4.5-p17、2.4.4-p18），补丁级别更低的必须先升到那个级别（见 KA-37421），Magento Open Source 的独立补丁下载仅提供 2.4.6 及以上；二是 Sansec 的 PolyShell 页面称 2.4.9 的 5 月版已含修复，但 Adobe 公告与 CVE 记录都把 2.4.9 列为受影响、2.4.9-2026-jul 列为修复，以 Adobe 列表为准；三是 Cloud 上的 Adobe Commerce 走 cloud-patches 通道更新。四条 KEV 元数据也值得抄下来：勒索软件使用情况 Unknown、自动化利用 No、技术影响 Total、取证分诊 Not required。

修复建议：顺序错了等于没修——先确认补丁、再清植入物、最后轮换凭据，三步不能颠倒。第一步确认补丁到位：用 php bin/magento --version 取实际版本并对照 APSB26-73，别拿包管理器版本号充数；如果你的补丁级别低于该分支最高级别，先升级别再打独立补丁；云上商家用 Adobe 的 Commerce Version Tool 与 Quality Patches Tool 核对。第二步找植入物（打补丁不会替你删文件）：查 pub/media/custom_options/ 与 pub/media/customer_address/ 下所有非 .htaccess 的文件，重点找伪装成图片的 PHP；全盘 find . -name 'accesson.php'；查 cms_block 与 cms_page 表，内容里出现 fpCode、se_referrer、localStorage.getItem 任一即中招（加载器域名常被 base64 编码，别只搜明文域名）；核对 admin_user 表里有无陌生账号，同时看有没有异常进程。第三步清完再轮换数据库、管理员与 API 集成三套密码。在 web 服务器层面对 pub/media/custom_options/ 下发全量拒绝访问规则——这能挡住执行，但挡不住上传本身，别误以为做完就等于修好。最后把这条经验固化：Magento 每次以源码形式发布补丁，攻击者几天内就能 diff 出漏洞——补丁就是利用说明书，升级涉及支付链路所以商家普遍拖，拖到几个月正是攻击者需要的窗口期。

满分CVE-2026-20127CVSS 10.0

思科 SD-WAN 控制器里的 KeyDrift：把分支间加密密钥从合法进程内部抽走（CVSS 10.0·CWE-288·10/28 Talos 披露·在野利用）

思科 Talos 于 10 月 28 日公开了一份新的威胁分析，追踪编号 UAT-11473，目标是在思科 Catalyst SD-WAN 控制器上部署一套名为 KeyDrift 的定制恶意框架。CVE-2026-20127 本身是 2026 年 2 月披露的满分零日（CVSS 10.0），无需凭据即可绕过 Catalyst 控制器、管理器与验证器的对等认证环节，登录为一个高权限内部非 root 账号，进而通过 NETCONF 改写整个 SD-WAN  fabric 的配置；厂商明确表示没有 workaround，打补丁是唯一手段。本期的新东西是攻击侧的完整解剖：KeyDrift 由三个部件构成。PolyFlame（载荷名 libdssl.so）是主力内存驻留模块，通过被篡改的 runit 服务路径 /etc/sv/sshd/run 与 /etc/sv/aaamgr/run 启动，脚本 conf_sshd 枚举运行中的 vdaemon 控制面进程 PID 并写入 /tmp/system-vdaemon，再用注入器 rsshd 经 ptrace 把 PolyFlame 塞进每个 vdaemon；它 hook recvfrom、sendto、getpeername、dlopen、dlsym、mprotect 与 /proc/%d/maps 解析，直接拿到 DTLS 会话密钥、vEdge 拓扑、OMP 路由与策略表，同时提供 TinyShell 风格后门（可执行命令、上传与下载文件，不支持交互式 shell）与中继 C2 能力；一个变体伪装成被打包的 aaamgrd，用 RC4 加密载荷、直接系统调用，并检查 TracerPid 反调试。LittleFilch（libcommon.so）负责偷密钥：hook 住 vdaemon 内的 SSL_read，在控制消息解密后按预设的边缘节点清单抽出公网传输地址、对端系统地址，以及一个 32 字节字段——Talos 判断那是 经 OMP 分发的 IPsec 数据面 AES-256 密钥材料；收集结果经 RSA 加密写入 /var/tmp/vdaemon.bin，并可用伪装成 DTLS 1.2 应用数据记录的 UDP 发出，外传配置在 /var/tmp/vdaemon.conf、读取后即删除。现场还发现 时间戳伪造（touch --reference=、chmod --reference=），说明框架仍在迭代。有两处归属口径必须说清：Talos 评估 UAT-11473 的基础设施与 Volt Typhoon 的 \"Silent Train\" 隐蔽接入网高度重叠，但明确没有说两者就是同一组织；同一天 Lumen Black Lotus Labs 披露 Silent Train 自 2023 年底起被监控，流量经由被攻陷的小型办公路由器、IoT 设备与企业系统层层转发、会话结束后清理现场，已致数百起受害者通知，确认的零日行动至少四起（Versa Director、N-able N-central、Cisco Catalyst SD-WAN、VeloCloud Orchestrator）另一起疑似针对 Quest KACE，Volt Typhoon 自 2025 年底起利用本 CVE，并在 2026 年 2 月思科公开披露之后仍在继续。受害面集中在航天与卫星服务、国防航空航天、政策研究，目标地域以夏威夷、加利福尼亚、德克萨斯最多。另一条要一并记：CVE-2026-20182 复用同一个 vdaemon 服务，同样已被利用。

影响范围

思科 Catalyst SD-WAN Controller、Manager 与 Validator 的对等认证环节，受影响的是全部在运行的控制器实例（vSmart、vManage、vBond）。修复版本：20.9.8.2、20.12.6.1、20.15.4.2、20.18.2.1（按分支对应）；低于 20.9 的版本没有同分支修复，必须迁到受支持的发布线。厂商在 2026 年 2 月披露时即已提供修复，但按 Talos 口径这些入侵活动属于\"历史事件\"、未披露具体入侵时间，也未确认被窃密钥是否已外传——Talos 的表述是\"以定向密钥收集为目标\"，并未证明所有被控部署都遭到过往流量的全面解密。该 CVE 已于 2026 年 2 月 25 日进入 KEV，本期讲的是其攻击侧生态的完整披露。

修复建议：升级只是关门，里面的人还得清。第一步核对每一台控制器（vSmart、vManage、vBond）的实际 build 是否在 20.9.8.2 / 20.12.6.1 / 20.15.4.2 / 20.18.2.1 及其之上，低于 20.9 的直接排迁移计划，不要试图在老分支上打补丁。第二步——如果这台设备在 2026 年 2 月修复之前曾经暴露在公网，就必须按 KeyDrift 的痕迹做一次完整排查，而不能升完补丁就收工：检查 /etc/sv/sshd/ 与 /etc/sv/aaamgr/ 两个 runit 启动脚本是否被改动（ls -la 加 cat 看 run 文件）、/tmp/system-vdaemon、/var/tmp/vdaemon.bin、/var/tmp/vdaemon.conf 三个路径是否存在、mount | grep rootfs 里可写 overlay 是否被改成可执行；再查 /var/log/auth.log 里\"Accepted publickey for vmanage-admin\"条目中的来源 IP 是否有陌生的。第三步，把控制器管理面（SSH 22 与 NETCONF 830）限制到已知的控制器地址，并记住这不能清除已植入的恶意代码。第四步，在联系思科 TAC 之前先在每台控制组件上执行 request admin-tech 收集支持包。第四步的实际含义要说透：这套框架是专门为\"长期安静驻留\"设计的，打补丁关的是门，不是把人赶出去。最后一条口径要记住：没有硬编码的 IP、端口、回调域名与轮询间隔可依赖，Talos 公布的文件路径与检测规则就是全部线索，任何一处命中都意味着事件响应，而不是跑个清理脚本。

高危CVE-2026-76418CVSS 8.6

思科防火墙 SSL VPN 第二个零日：不用登录，一个请求把边界设备打到重启（CVSS v3.1 8.6·CWE-690·10/28 通告·在野利用·无 workaround）

思科于 10 月 28 日 19:15 UTC 发布最终版公告 cisco-sa-asaftd-tunnel-dos-s6mgkb75，Bug ID CSCwx26625，CWE-690（不正确的内存读取/边界处理），CVSS v3.1 8.6（AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H，E:X/RL:X/RC:X）。漏洞机理在思科的表述里很直白：当隧道组上配置了二次认证（secondary authentication）时存在逻辑错误，攻击者在连接 SSL 远程访问 VPN 的过程中发送一个构造请求即可让设备意外 reload，形成拒绝服务。三个前置条件必须同时成立：设备运行受影响版本的 ASA 或 FTD、SSL VPN 登录服务可达、受影响范围内的隧道组配置了二次认证。思科公告里那句最关键：不需要 VPN 登录成功就能触达受影响的处理路径——也就是说攻击者的请求根本不必伪装成一次成功的认证，它只是\"连接过程中的一次请求\"。这条漏洞由 Eric Fernald 在处理一个思科 TAC 支持工单的过程中发现，2026 年 10 月思科 PSIRT 获知存在活跃利用（厂商未归因、也未公开 IoC）。这是今年夏天以来第二个被武器化的思科防火墙 VPN 零日：8 月修的 CVE-2026-20349 是远程访问 SSL VPN 服务里未认证的 HTTP 请求处理缺陷，同样是让设备远程 reload；是否同一伙人，官方与外部分析都没有确认。CISA 于 10 月 29 日把它收进 KEV，联邦截止日 11 月 1 日。CISA 的 SSVC 评估把技术影响记为 Partial，并按 BOD 26-04 对\"部分控制\"的定义说明——拒绝服务攻击构成对脆弱组件行为的有限控制，所以这条的判定轴是可用性，不是机密性：向量里 C 与 I 都是 N，没有数据泄露、没有配置篡改。但 braindetox 那篇分析说得更实在：单台设备做冗余和单台设备扛全部远程接入，打分完全一样，但实际业务中断程度天差地别。厂商给的缓解措施要读仔细，因为它分两种情形，且没有\"官方 workaround\"，只有降风险的缓解：情形一是 DefaultWEBVPNGroup 未使用二次认证，则在 WebVPN 配置模式下执行 no tunnel-group-list enable 关闭组列表——副作用是用户不再能从列表里选连接配置，必须知道正确的配置名；情形二是 DefaultWEBVPNGroup 用了二次认证，则执行 no secondary-authentication-server-group 移除二次认证，这会直接降低远程接入 VPN 的安全水位。思科自己强调：这个缓解在测试环境验证有效，但客户必须自行评估适用性，且任何缓解都可能影响功能、性能与安全态势。CVE 记录里受影响版本清单很长——142 个 ASA 版本、67 个 FTD 版本。

影响范围

思科 Secure Firewall ASA Software：9.16 及更早 → 修 9.16.4.104；9.18 → 9.18.4.96；9.20 → 9.20.4.50；9.22 → 9.22.3.200；9.23 → 9.23.1.48；9.24 → 9.24.1.27 与 9.24.10.1。思科 Secure FTD Software：7.0 及更早 → 修 7.0.11；7.2 → 7.2.13；7.4 → 7.4.9；7.6 → 7.6.7；7.7 → 7.7.14；10.0 → 10.0.3；10.1 → 10.1.1。明确不受影响：Cloud-delivered Firewall（CDFW）、Cloud-delivered Firewall Management Center（cdFMC）、Secure Access（CSA）、Secure FMC Software。判定暴露的两条命令路径要背下来：运行配置里含 webvpn 关键字且至少一个接口上 enable（FTD 侧则在 FMC 的 Devices > VPN > Remote Access 或 FDM 的 Remote Access VPN 里确认）；若配了 tunnel-group-list enable，要检查所有隧道组，包括默认组 DefaultWEBVPNGroup——这个检查不能只限于登录页上显示出来的那些配置；若 tunnel-group-list enable 不存在或已被 no tunnel-group-list enable 删除，仍要检查 DefaultWEBVPNGroup 是否配了 secondary-authentication-server-group，因为在默认组使用二次认证的情况下，仅关闭组列表并不能消除暴露。

修复建议：先判定暴露面，再决定是打补丁还是先缓解。第一步用 show running-config（FTD 上从 FMC / FDM 导出运行配置）确认三件事：是否开启 SSL 远程接入 VPN、哪些接口 enable、哪些隧道组配了 secondary-authentication-server-group——这一步不做，升级清单就无从谈起。第二步按分支升到对应修复版本，升级后逐台验证 SSL VPN 会话建立、二次认证流程、隧道组列表行为与 HA 切换，并把升级前后的 build 号写进变更单。第三步，若暂时无法升级，按上面两种情形选一种缓解：默认组没用二次认证就 no tunnel-group-list enable（并提前通知用户\"现在要手填配置名\"）；默认组用了二次认证就 no secondary-authentication-server-group——做这个决定前先想清楚你在拿什么换可用性，很多单位用二次认证做 MFA 强校验，关掉等于把 MFA 一并摘了。第四步，在网络层做访问收敛：能收敛的就把 SSL VPN 登录服务的可达范围限制到必要的源地址段。第五步是这条漏洞最实际的取证动作：回头查 2026 年 10 月以来的异常 reload、崩溃信息与 syslog 缺口——因为成功利用不需要登录成功，攻击痕迹很可能根本不会出现在失败或成功的认证事件里，只翻认证日志会漏掉全部。第六步，把这条和 8 月那条 CVE-2026-20349 放在一起评估：同一服务半年内被零日打了两次，说明这条边界设备的前门没有系统性加固，只补单个洞是不够的。

严重CVE-2026-97631CVSS 9.5

EDK II 的 PXE 驱动躺了 16 年：操作系统还没加载，代码已经跑了（CVSS v4.0 9.5·CWE-787·10/22 公告·无稳定版修复）

这一条是本期最\"硬\"的一条。TianoCore EDK II 是绝大多数硬件厂商构建 UEFI 固件的开源参考实现，AMI、Insyde、Phoenix 这些独立 BIOS 厂商都大量使用，微软加固过的分支 Project Mu 也带着这段有问题的代码。缺陷落在 PXE Base Code 驱动（NetworkPkg/UefiPxeBcDxe）：PXE 网络引导期间，该驱动会保持一个接收 ICMP 差错报文的请求处于打开状态，并把收到的每条报文拷进私有上下文结构里一个固定 504 字节的字段 Mode.IcmpError。边界处理在 IPv4（PxeBcIcmpErrorDpcHandle）与 IPv6（PxeBcIcmp6ErrorDpcHandle）两条路径上都是错的——报文超过 504 字节时仍然继续拷贝，而且目标指针按累计长度推进、而不是按分片长度推进，于是超长报文把攻击者控制的字节写到字段之外，覆盖相邻内存。接收路径上更早的任何一步都没有对消息长度设限。这段有问题的代码可以追溯到 2010 年 11 月的一次提交，至今约 16 年。两种后果难度天差地别：容易的那个是崩溃——DXE 核心里触发 CPU 异常、启动过程挂死，等于让 OS 部署与恢复变成不可用；难的那个是代码执行——公告明确写明：知道目标固件确切构建的攻击者可以在同一报文里植入一个伪造事件，让固件在 ring 0 分发攻击者提供的字节。这段代码运行在操作系统与 Secure Boot、measured boot 校验全部建立之前，因此不能指望 Secure Boot 来挡——被篡改的是合法签名的固件代码本身，Secure Boot 不会报警。触发门槛不算苛刻：无需口令、无需任何既有访问，只需能在 PXE 引导窗口内向目标 IP 投递一条单播 ICMP 差错报文；TianoCore 公告的说法是\"可从任意网络距离投递\"，而 Red Hat 与 SUSE 评估为\"需邻接网络位置\"——这个差别很重要，它覆盖了任何共用办公网段、VLAN 配置不当、或已被渗透设备所在的区段。代码执行本身不会随重启自动持久，跑一次就结束，但这一次足够装下每次开机都跑的东西，还可能破坏磁盘加密、绕过远程证明。披露过程本身就是一条教训：原定的协同披露定在 2027 年 1 月，但 9 月 28 日一个由 AMI 工程师签署的合并请求被公开，里面既描述了漏洞也带着修复——修复代码公开的那一刻，等于把利用规格发给了所有人；TianoCore 于 10 月 22 日发布公开公告，NVD/MITRE 同日收录该 CVE。修复代码 10 月 15 日合进上游主分支，但至今没有任何稳定版 EDK II 包含它（最新稳定版 edk2-stable202608 发布于 8 月 21 日，仍带漏洞）。截至 10 月 27 日版本的 KEV 目录，这条未被收录，也没有任何研究者报告看到它被实际利用——但在一条操作系统加载前才执行的漏洞上，\"没有报告\"不等于\"没有发生\"。厂商立场也参差：英特尔表示其仍在安全支持期内的商用产品未发现受影响，且其参考代码不包含相关功能（但 OEM 板卡或整机厂商自行加入则另说）；Arm 称该漏洞不直接适用于其产品线；AMD、Phoenix、AMI、微软与亚马逊在发稿前均未回应。

影响范围

EDK II 至 edk2-stable202608（含） 全部版本，以及 2026 年 9 月 14 日时的主分支。Linux 发行版侧：Red Hat 已将 RHEL 8、9、10 中的 edk2 标记为受影响且暂无勘误（no errata）；SUSE 与 Debian 的对应软件包同样受影响且尚未修补。真实暴露面取决于两件事：设备的固件是否包含受影响的 PXE 驱动，以及设备是否真的走 PXE 网络引导——仅从本地硬盘或 SSD 启动的系统不受这条影响，家里和小型办公设备风险有限。数据中心场景值得重点关注：PXE 被广泛用于服务器部署、系统安装与恢复，PXE 引导或无盘运行的服务器、存储设备是主要风险面；另外嵌入式与楼宇类设备（NVR、门禁面板等）是否落在范围内没有任何来源确认过具体设备类别是否使用该驱动、是否支持 PXE 引导，只能逐家向厂商确认。

修复建议：这一条的核心结论是\"现在没有补丁可打\"，所以动作必须落在\"减少暴露 + 推动厂商\"上。第一步，立即清点资产：列出所有可能走 PXE 网络引导的设备（服务器、存储设备、装机线、灾备恢复环境、以及楼宇里的嵌入式设备），并逐台向固件与整机厂商索取引用 CVE-2026-97631 的固件更新，拿到就按厂商指引刷写——这是唯一真正的修复动作，且周期由厂商决定，不是你能控制的。第二步，对不需要网络引导的设备立即关闭 PXE / 网络启动，这一条不依赖任何厂商动作，是当下唯一能立刻生效的处置。第三步，必须保留 PXE 的场景：把引导网络放到受信且隔离的网段，并过滤掉未经授权的 ICMPv4 与 ICMPv6 流量（尤其是流向 PXE 引导中设备的）——这条听起来别扭，但它是当前唯一能压住利用面的网络手段。第四步，别把另一个 EDK II 漏洞搞混：CVE-2025-2296 是另一个独立的 EDK2 BIOS 缺陷，由 SentinelOne 收录，需要本地已认证访问，与这条完全不需要凭据、纯靠网络触发的漏洞不是一回事。第五步，把这条写进采购与续约要求：要求供应商在安全公告中标注是否包含 EDK II 上游修复、以及本次固件构建对应的 edk2-stable 版本，因为\"上游已修\"与\"你能装到\"之间隔着一条漫长的固件发布链——嵌入式楼宇设备的固件发布周期尤其长。

高危CVE-2026-46300CVSS 7.8

Linux 内核 Fragnesia：只改内存里的页缓存，磁盘上的文件完全干净（CVSS v3.1 7.8·CWE-787·10/28 入 KEV·公开 PoC 与 Metasploit 模块）

名字取得很贴切——\"Fragnesia\"（遗忘症），因为核心缺陷不是缺少检查，而是skb 在合并时\"忘了\"某个 fragment 是共享的。2026 年 5 月 13 日 v12-security 团队的 William Bowling 在 oss-security 公开披露，Greg Kroah-Hartman 随后指派了 CVE-2026-46300，Wiz 发布了详细技术分析。机制在 net: skbuff: preserve shared-frag marker during coalescing 这个修复标题里已经说尽：TCP 收包合并时，skb_try_coalesce() 可以把 paged fragment 从 @from 挂到 @to 上；如果 @from 带 SKBFL_SHARED_FRAG 标记，合出来的 @to 里可能仍带着同一批外部所有或页缓存支撑的 fragment，但这个共享标记在合并过程中丢失了——而后续的就地写入者正是靠这个标记做判断。IPsec ESP 输入路径会先检查 skb_has_shared_frag()，再决定一个未克隆的非线性 skb 能否跳过 skb_cow_data()；标记一丢，ESP 就认为\"可以就地解密\"，于是把 AES-GCM 的输出直接写进只读文件的页缓存页面。攻击面因此极窄也极深：受影响的是 XFRM ESP-in-TCP 子系统（esp4 / esp6），也就是那些把 IPsec-over-TCP 终结在本机的场景。披露原文说得很克制也很吓人：它\"在不需要任何竞态条件的前提下，实现对只读文件内核页缓存的任意字节写\"；具体手法是——当一个 TCP socket 在数据已经从文件 splice 进接收队列之后才切换到 espintcp ULP 模式，内核会把队列里的文件页当作 ESP 密文处理，AES-GCM 密钥流中计数器块位置 2、字节 0 被直接 XOR 进缓存的文件页；攻击者通过选择 IV nonce 产出期望的密钥流字节，就能把文件里任意目标字节设成任意值，每次触发写一个字节。利用程序构建一张 256 项的映射表（每个可能的密钥流字节 → 产生它的 nonce），然后逐字节走完载荷，写入 192 字节的位置无关 ELF 桩代码（setresuid、setresgid、execve /bin/sh）覆盖 /usr/bin/su 的头部，随后执行 su 就拿到了 root。\"页缓存里的修改不会回写磁盘，磁盘上的二进制原封未动\"——这句话决定了整条漏洞的处置方式，也决定了它的取证困境：被污染的 /usr/bin/su 只作为脏页存在于内存中，研究者在 PoC README 的\"Critical Cleanup Warning\"里写明：利用跑完后 /usr/bin/su 的页缓存里仍含注入的桩代码，此后每次执行 su 都会重新拉起 shell，直到该页被换出；离开机器前请 drop 缓存或重启（echo 1 | tee /proc/sys/vm/drop_caches）——攻击者的卫生习惯与调查者的证据损失，是同一条命令。证据消失有三条路径，其中两条还是尽职的操作者主动做的：一是脏页被换出，二是打补丁意味着跑新内核、新内核意味着重启，三是 CISA 给这条打了 forensicTriage: Yes——在当时的 1762 条 KEV 目录里只有 94 条带这个标记，且全部是 2026 年新增、当月就有 22 条。而 KEV 录入时附带的评分是 2.7，内核官方与 NVD 记录是 7.8（AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H）——低分恰恰说明它不会自己传播：它需要先有一个本地立足点，所以在内网资产优先级里要往前提，但别指望它像 PHP2Shell 那样从互联网打进来。此外 KEV 与厂商口径还有一点差异要说清：意大利 CSIRT 报告公开 PoC 存在、但随附通告未报告主动利用；Rapid7 的 Metasploit 模块已可用数月。Rapid7 把源头追溯到 kernel 4.10，Hive Pro 则认为它是 Dirty Frag 修复的副作用——这一族在 2026 年 5 月两周内连出四五个洞（Copy Fail 的 CVE-2026-31431、Dirty Frag 双条 CVE-2026-43284 与 CVE-2026-43500、以及本条，另有 ZDI-CAN-33367 这个 Dirty Frag 续作），该族还在持续产出新洞。Canonical 另指出：在运行第三方工作负载的宿主上，这条洞还可能通向容器逃逸，不过尚无容器逃逸 PoC 公布。

影响范围

Linux 内核网络栈，通过 XFRM ESP-in-TCP（esp4 / esp6）可达，受影响范围是全部运行受影响内核的 Linux 主机。KISA 公布的已修复内核版本：5.10.257、5.15.208、6.1.174、6.6.141、6.12.91、6.18.33、7.0.10——请用你所用分支对应的那个或更新的版本，不同发行版的回补号完全不同，别直接套用上游号。发行版受影响产品包括 RHEL、AlmaLinux、Debian 与 Red Hat OpenShift Container Platform。上游 stable 分支修复提交包括 3599e6b3cc1a、2f2b16022a2e、9d3e5fd19fe1 等，可用它们在补丁管理系统里定位对应发行版回补。触发前提：目标主机必须启用并在接收路径上实际经过 ESP-in-TCP——只跑普通 TCP、不终结 IPsec 的主机不会被这条路径命中，这一点决定了你在做资产盘点时该怎么划线。无补丁时的临时缓解是阻塞并卸载相关内核模块，但官方与多方提醒：这可能中断业务、模块正在使用中时卸载会失败、且对已发生的失陷没有任何补救作用。

修复建议：这条唯一的正确顺序是\"先取证、再修、最后才重启\"。第一步，在动手之前把证据固定下来：把受影响主机的内存镜像、网络抓包与 /var/log 里的登录与提权记录按事件响应手册归档——因为打补丁本身就会重启，重启就是证据销毁，而这条洞在 KEV 里明确带 forensicTriage: Yes。第二步，重点排查\"只改了内存、磁盘干净\"这个特征：页缓存被污染的文件在磁盘上是完好的，所以文件哈希校验在此完全失效；可行的高信号线索是行为异常——Web 服务账户派生 shell、/usr/bin/su 之类的特权二进制出现异常调用、静态内容文件哈希在重启前后不一致、mmap 相关崩溃。第三步，按分支升级到对应发行版的已修复内核版本（对照你发行版的追踪表，不要照抄上游号），云镜像与 golden AMI 一并盘点，否则重建镜像会把旧内核带回来。第四步，如果确实无法立刻打补丁，可临时阻塞并卸载相关内核模块以降低暴露，但要事先评估业务影响、确认模块未被占用，并且明确这只是权宜之计。第五步，把这一族的洞当成一件事来管：Copy Fail、Dirty Frag、ZDI-CAN-33367 都在同一片页缓存逻辑上，逐个 CVE 单独跟踪会一直漏——建议按\"页缓存写原语\"这一类去做一次整体性的资产与补丁梳理。

高危CVE-2026-41709CVSS 7.6

VMware ESXi 的日志漏洞进了 KEV：它不给权限，它专门负责让痕迹消失（CVSS v3.1 7.6·insufficient logging·10/28 入 KEV·Warp Panda 零日利用）

这一条在 KEV 列表里长得很特别：它本身不提供任何权限，但它是\"让权限不留痕迹\"的那一类漏洞。CISA 于 10 月 28 日把 CVE-2026-41709（Broadcom VMware ESX Insufficient Logging Vulnerability，CVSS 7.6） 收进 KEV，联邦截止日 11 月 11 日。机理直白到近乎朴素：拥有管理员权限的用户可以在受影响系统上执行某些操作，而这些操作不会被记录到日志里——日志不记录这件事本身就是缺陷，思科式的分类是 A09:2025 安全日志与告警失效。该漏洞本身不授予管理员权限，攻击者必须先已经有管理员权限；它的价值在于让攻击者在已经拿到权限之后，还能把操作痕迹从审计轨迹里抹掉。Broadcom 已于 7 月发布补丁，那次一共修了影响 VMware ESXi、vCenter、Workstation 与 Fusion 的五个漏洞，CVE-2026-41709 是其中之一。在野利用的证据来自 CrowdStrike《2026 法律威胁态势报告》：中国关联组织 Warp Panda（又名 Armory Castle / UNC5221 / Clay Typhoon / VerdantBamboo）在 2026 年初把它当作零日利用，目的是降低自身活动在审计日志中的可见度；该组织的画像一贯是——针对互联网暴露的边缘设备、利用零日部署定制化恶意软件维持长期隐蔽访问，并试图通过绕过审计日志、窃取云会话令牌、注册未授权的多因素认证设备来规避检测。这一条与前面几条串起来看，才是本期真正的主线：一个攻击者要在已被入侵的宿主上做长期驻留，最缺的不是入口，而是\"日志里看不见\"这个能力——所以厂商愿意为一条 7.6 分、不能提权的日志缺陷发补丁并被 CISA 认定为在野利用，这也说明审计日志本身已经是攻击目标，而不是只记录工具。

影响范围

Broadcom VMware ESX（ESXi 宿主），受影响的是全部在运行的 ESXi 实例——注意区分 ESXi 宿主与 vCenter：这条落在 ESX/ESXi 侧，但 vCenter 的集中日志与合规报表恰恰是它的下游，一旦宿主侧日志缺了，上层的合规视图会显示\"一切正常\"。漏洞早在 2026 年 7 月就已发布补丁，因此这段时间内在野利用的版本大概率是 7 月补丁之前的旧版本。CISA 未把勒索软件关联写明（Unknown），技术影响评估为完全。这一条还有一层现实提醒：由于\"日志不记录\"这个缺陷本身不会被常规资产扫描发现，它不会出现在任何漏洞扫描报告里——只能靠版本比对与日志完整性分析来发现。

修复建议：这一条的处置逻辑与其他条目不同，重点不在\"打补丁\"本身，而在\"补完之后要意识到日志早就不全了\"。第一步，核对 ESXi 的实际版本是否已包含 7 月那批修复，特别是那些停止订阅、错过 7 月更新的实例——它们是这波在野利用的最可能载体，也是最容易被资产清单漏掉的一批。第二步，打补丁之后不要相信历史日志：对已经装机的 ESXi，回溯审计日志时要把\"日志缺失\"本身当作一个检测信号来用——在关键时间窗内没有对应记录的操作，恰恰是最可疑的操作；把这条思路写进日常的日志完整性巡检，比单纯核对版本号有价值得多。第三步，确认日志外送路径没有被一并削弱：如果贵单位把 ESXi 日志集中送到 SIEM，要验证这段外送链路本身有没有被同一个攻击者动过手脚——Warp Panda 的其他习惯动作包括窃取云会话令牌与注册未授权 MFA 设备，审计外送凭据也要一起轮换。第四步，把这条和上一期的边界设备经验放在一起：\"干净的主机\"不等于\"没被入侵\"——一个攻击者有能力让日志闭嘴的环境里，任何基于日志的结论都需要额外的旁证。第五步，资产清点时把 ESXi 主机的管理接口暴露面单列出来，因为这一族的攻击者都是先拿边缘设备、再谈别的。

紧急提醒

本期最高优先级是 Cisco SD-WAN 控制器的 KeyDrift，理由与其他条目都不一样：别的洞偷的是\"一台服务器\"，这个洞偷的是\"你们所有分支之间的加密密钥\"。

PolyShell 偷的是店铺，CVE-2026-76418 打的是可用性，Fragnesia 提的是本地 root，EDK II 那个要开着 PXE 引导才够得着——都还有边界。但 KeyDrift 完全不同：它住在你自己厂商的合法进程里（PolyFlame 注入 vdaemon），用的是合法签名的固件路径，通过控制面自己的 DTLS 加密信道通信，不硬编码任何 IP、端口、回调域名与轮询间隔，唯一的门禁是攻击者发的任务里带的那串日期 MD5 与设备当前日期对得上。这一整套设计的目的就是活得久、看不见、还能把密钥抽走——LittleFilch 在 vdaemon 内部 hook SSL_read，等控制消息解密之后再动手，抽走的是 OMP 分发的 IPsec 数据面 AES-256 密钥材料。拿到这些密钥、再加上已经身处 SD-WAN fabric 内部这个位置，加密流量的实际机密性就失去了保障。

而最该让人不安的是时间线：Volt Typhoon 自 2025 年底开始利用，2026 年 2 月思科公开披露并给出补丁之后仍然继续；Lumen 侧记录的是 Silent Train 这张网至少发动过四起零日行动，横跨 Versa Director、N-able N-central、Cisco Catalyst SD-WAN 与 VeloCloud Orchestrator，受害者遍及电信、政府、国防承包商、卫星与任务关键通信、MSP、与军方有渊源的大学与关键基础设施运营方。这不是一次单点入侵，是一套可复用的武器库在多类管理平面上反复使用。

所以排查优先级这样排：第一顺位是 SD-WAN 控制器——不是因为它现在还能被打进（2 月就修了），而是因为在 2026 年 2 月之前暴露过的控制器，现在必须按入侵对待：查 /etc/sv/sshd/run 与 /etc/sv/aaamgr/run 是否被改、/tmp/system-vdaemon 与 /var/tmp/vdaemon.bin 是否存在、/var/log/auth.log 里有没有来源陌生的 vmanage-admin 公钥登录。任何一处命中都是事件响应，不是清理脚本。第二顺位是今天必须动的 Fragnesia（联邦截止日 10 月 31 日，实际留给私界不足一天），而且取证要在重启之前——这条洞最反直觉的地方就是磁盘上的文件看起来完好无损，所有证据都在内存里，而你的修复动作恰好会把它抹掉。第三顺位是 Magento 商店，重点是别把\"打了补丁\"当成\"已经干净\"：补丁只挡新的上传，三个月前灌进去的 Web Shell、伪装的 PHP 与被改过的 CMS 区块都还在，而且 3 月 30 日那一小时就中了 471 家的规模说明扫描器早就把这批资产扫完了。第四顺位是 EDK II——这条你今天能做的只有\"关掉不需要的 PXE 引导\"和\"把引导网段隔离\"，剩下的只能靠厂商什么时候发固件。

处置建议

① 思科 SD-WAN 控制器：先按入侵假设排查，再谈升级。 逐台检查 /etc/sv/sshd/run 与 /etc/sv/aaamgr/run 的 runit 启动脚本是否被篡改（重点看有没有 remount /rootfs.rw 与后台拉起 conf_sshd 的两行）、/tmp/system-vdaemon、/var/tmp/vdaemon.bin、/var/tmp/vdaemon.conf 三个文件是否存在、mount | grep rootfs 里可写 overlay 是否被改成可执行；在 /var/log/auth.log 里搜 Accepted publickey for vmanage-admin，核对来源 IP 是否在已知运维出口范围内。确认版本已到 20.9.8.2 / 20.12.6.1 / 20.15.4.2 / 20.18.2.1，低于 20.9 的排迁移而不是硬打补丁。

② Magento / Adobe Commerce：按\"补丁 → 清植入物 → 轮换凭据\"三步走，别跳步。 用 php bin/magento --version 对照 APSB26-73 确认补丁真实到位（独立补丁只适用于该分支最高补丁级别，级别更低的要先升级别）；然后查 pub/media/custom_options/ 与 pub/media/customer_address/ 下的伪装图片文件、全盘搜 accesson.php、在 cms_block 与 cms_page 里搜 fpCode / se_referrer / localStorage.getItem、核对 admin_user 有无陌生账号；最后轮换数据库、管理员与 API 集成三套密码，并在 web 服务器层封禁 pub/media/custom_options/ 下的执行。清干净再轮换凭据，顺序反了等于白做。

③ 所有跑 IPsec ESP-in-TCP 的 Linux 主机：今天就要动，且取证在重启之前。 联邦截止日 10 月 31 日，实际留给私界的窗口不足 24 小时。先把内存镜像、网络抓包与 /var/log 按事件响应手册归档（这条 KEV 带 forensicTriage: Yes，而打补丁必然重启、重启就是销毁证据）；再按你所用发行版追踪表升级到对应修复内核（对照发行版回补号，别直接抄上游 5.10.257 / 6.1.174 这些数字）；排查时记住特征是\"磁盘干净、内存脏\"，文件哈希校验在这里完全失效，要看的是行为异常——Web 服务账户派生 shell、特权二进制被异常调用、静态内容重启前后哈希不一致。同时把 Copy Fail、Dirty Frag、ZDI-CAN-33367 当成同一族一起梳理，别只修一条。

④ 所有 PXE 网络引导的设备：今天把不需要的引导关掉。 这一条不依赖任何补丁。列出所有走网络引导的服务器、存储设备、装机线与灾备恢复环境，逐台向固件与整机厂商索取引用 CVE-2026-97631 的更新；不需要网络引导的立即关闭 PXE，必须保留的把引导网段隔离并过滤未经授权的 ICMPv4 / ICMPv6。顺带把楼宇里的嵌入式设备（NVR、门禁面板等）也纳入清点——没人能确认它们是否用了这个驱动，那就去问厂商。

⑤ 所有 ASA / FTD：先查配置条件，再决定打补丁还是先缓解。 用 show running-config 确认是否开启 SSL 远程接入 VPN、哪些接口 enable、哪些隧道组配了 secondary-authentication-server-group（含默认组 DefaultWEBVPNGroup，即使 tunnel-group-list enable 已被删除也要查）；按分支升到 9.16.4.104 / 9.18.4.96 / 9.20.4.50 / 9.22.3.200 / 9.23.1.48 / 9.24.1.27 / 9.24.10.1（FTD 对应 7.0.11 / 7.2.13 / 7.4.9 / 7.6.7 / 7.7.14 / 10.0.3 / 10.1.1），并逐台验证 SSL VPN 会话、二次认证流程、隧道组列表行为与 HA 切换。暂不能升级的按厂商两种情形选缓解（no tunnel-group-list enable 或 no secondary-authentication-server-group），但要清楚这等于摘掉了一层 MFA 校验。同时把 22 与 830 端口的可达范围收窄。

⑥ 取证别只翻认证日志。 CVE-2026-76418 的成功利用不需要登录成功，攻击痕迹很可能不会出现在失败或成功的认证事件里——回溯 2026 年 10 月以来的异常 reload、崩溃信息与 syslog 缺口才是有效路径。同理，VMware ESXi 那边打补丁后不要相信历史日志：把\"关键时间窗内没有对应记录的操作\"当作检测信号来用，并确认日志外送到 SIEM 的链路与外送凭据没被同一个攻击者动过手脚（\"日志里没有\"和\"日志没记下来\"是两件事，后者更危险）。

⑦ 把这一期的教训写成一条资产级规则。 这一期六个洞里有三个（Cisco 两个 + VMware ESXi 一个）的共同点不是\"能被利用\"，而是\"被利用了但你查不出来\"——设备被重启不留认证记录、密钥被抽走不留外部连接、日志被关掉不留痕迹。建议在资产台账里为每台边界设备与虚拟化管理节点单列一栏\"日志完整性基线\"：记录正常情况下每天的日志条数、关键操作的应有记录、syslog 外送的中断点，偏离基线本身就是告警。同时把\"管理平面/汇聚平台/审计平台\"从\"普通资产\"里拎出来单独管——它们一旦被拿下，你对全网的其余部分就失去了眼睛。

觉得有用？点击右下角在看，让更多人看到