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

探知安全
探知安全

探知安全

2026年10月19日 10:26
江西

去阅读

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

2026年10月19日  |  探知安全

今日焦点

这一周的关键词不是\"哪个洞最满分\"，而是远程支持与网络管理这一层被同时打穿。BeyondTrust Remote Support 的认证绕过（CVE-2026-102764，CVSS v4.0 9.3）被中国关联间谍组织 ARMORY CASTLE 从 8 月 29 日就当作零日使用，攻击者装 PHP Web Shell SAWFLY、把 /bin/sh 复制成带 SUID 的 dbus-authd 拿 root、用自带的 bt-secrets 导光全部托管凭据，再改 haproxy.conf 架 SOCKS5 隧道 BARECLAW——补丁 10 月 8 日才发，公告 10 月 15 日，CISA 10 月 16 日入 KEV 并给出 10 月 19 日（即今天）截止。同一天进 KEV 的 Fortinet CVE-2025-61624 更值得复盘：Fortinet 自己只给 6.0 分、NVD 6.5，看上去人畜无害，却是 Palo Alto Unit 42 记录的 PEERSTITCH 行动的第二段钥匙——攻击者 2024 年 9 月从一台 FortiManager 拖走覆盖 500 多台防火墙的配置包，25 个月后靠这个\"管理员级路径遍历\"把管理 CLI 变成 root，写文件到 ../../../../setup 植入纯内存木马。FortiOS 管理员本没有 shell，一旦这台设备的管理平面被打穿，配置备份里什么都不剩。另外三条：Drupal 双 RCE（CVE-2026-108097/108099）官方罕见预警\"补丁公开后数小时到数天内可能出现利用\"；Plex Media Server 四漏洞链 Plex2Shell（最高 CVSS 8.6）在 PoC 发布次日即被在野使用挖矿劫持；F5 一次修 NGINX 11 个洞，三个 9.2 全是免认证堆溢出与 use-after-free。建议优先排查：所有自托管 BeyondTrust Remote Support/PRA 设备、所有以远程支持为运维入口的 MSP、以及运行 FortiManager 的任何单位——Fortinet 那台设备如果两年内没轮过密钥，打补丁不等于止损。

漏洞详情

严重CVE-2026-102764CVSS 9.3

BeyondTrust Remote Support 认证绕过：远程支持平台自己成了后门，七周零日窃走全部托管凭据（CVSS 9.3·10/16 入 KEV·联邦截止 10/19·中国关联 ARMORY CASTLE）

BeyondTrust 于 10 月 15 日发布安全公告 BT26-05，披露 Remote Support（原 Bomgar）内部消息组件未充分校验消息来源导致的认证绕过漏洞 CVE-2026-102764，CWE-290。厂商给出 CVSS v4.0 评分 9.3（CVSS v3.1 口径为 9.1），向量为网络可达、无需权限、无需用户交互。原理一句话：appliance 内部组件不验证收到的内部消息来自谁，在特定条件下攻击者可以对设备执行文件操作。它虽不是\"一进去就 root\"的洞，但从结果看没有任何区别。Mandiant 与 Google 威胁情报组（GTIG）把利用归因到 ARMORY CASTLE（原 UNC5221，CrowdStrike 称 Warp Panda），属中国关联间谍组织。完整时间线值得逐条读：8 月 29 日该组织对一台 BeyondTrust 托管实例与一台自托管设备动手；9 月 27 日，另一家安全设备厂商被曝遭成功利用（消息公开），BeyondTrust 被触发自查；9 月 28 日在托管实例上发现入侵并复现入口，当天 Mandiant 从自托管受害方确认，距首次利用已过 30 天；10 月 8 日补丁发布；10 月 15 日协调披露。BeyondTrust 自述从 web 服务账户到 root 只用了几分钟：植入轻量 PHP Web Shell SAWFLY（落地名 mangoapi.php，C2 通信用 Base32 + RC4 加密，不带特定参数时返回 404 以规避常规探测）；把 /bin/sh 复制到 /usr/bin/dbus-authd 并置 SUID 位完成提权；用设备自带的 bt-secrets 工具导出全部托管口令与 API Key；追加启动脚本向 sudoers 模板写入免密 sudo 实现重启存活；部署 BARECLAW——经 WebSocket 承载的 SOCKS5 隧道，通过修改 haproxy.conf 对外暴露；随后清空系统日志、Web 日志与 secrets 日志。最后用窃取的设备管理员凭据，从设备自身的 Jump Item 列表发起远程会话横向进入下游系统，并外传 IT 文档。BeyondTrust 称全球仅两台客户设备受影响、8 月之后未见新活动，但同时提醒：该组织历来在漏洞公开后会迅速转向广泛利用，此处务必不要把\"只有两家受害\"当成安慰。Shadowserver 追踪到超过 1400 台公网暴露的 Remote Support 实例，BeyondTrust 客户总数超 20000 家，财富 100 强中 75% 是其客户。

影响范围

BeyondTrust Remote Support 26.2.3 及更早版本的自托管部署（通告列出 26.2.3 之前全部版本，CVE 记录口径为含 26.2.3）。Privileged Remote Access（PRA）共享受影响代码，厂商自身测试未找到可利用路径，但仍发布了 PRA 补丁并建议自托管 PRA 客户立即安装。使用 BeyondTrust 托管 SaaS 的客户已于 10 月 8 日完成修复，无需动作。

修复建议：今天就动手，且顺序不能反。登录每台自托管设备的 /appliance 接口，核对版本号与已安装更新中是否有 BT26-05-RS，版本低于 24.3.1 的设备补丁装不上，必须先升级；同时确认设备是否订阅了自动更新——厂商明确说自托管客户在未开启自动更新时需手动打。打完补丁立即做行为式排查，而不是只扫文件：留意来自住宅宽带或商业 VPN 地址、无法对应到已知管理员或工单的特权/管理会话；Web 目录下的可疑脚本文件与 Web 服务账户派生 shell；未经授权的账户、权限、会话策略变更，尤其是对 Jump Items 或 Teams 的改动；在单次会话内开始又结束日志转发中断——攻击者离场前会删本地日志和自己的工具，设备上的证据可能已被破坏，只有转发到 SIEM 的异地副本往往才是可靠记录。发现疑似失陷立即隔离，先对虚拟设备做快照、对物理设备做取证镜像，再重建设备并打补丁，然后轮换该设备存储或注入过的每一份凭据、撤销所有活动支持会话、复查特权账号上新增的 MFA 注册，同时查 haproxy.conf 是否有异常修改、/usr/bin/dbus-authd 是否为 /bin/sh 的副本且带 SUID、系统与 Web 日志是否有缺口。Mandiant 已发布该组织工具的哈希与 YARA 规则可直接用于狩猎。另注意一处平台性问题：ARMORY CASTLE 自 2023 年 10 月起已多次利用 Citrix NetScaler 与 Ivanti Connect Secure 的零日（分别是 CVE-2023-4966、CVE-2023-46805、CVE-2024-21887、CVE-2025-0282），\"边缘设备\"是他们的固定目标清单，不是随机选择。

高危CVE-2025-61624CVSS 6.5

Fortinet FortiOS 命令行路径遍历：6.0 分的\"中危洞\"，两年后成了 500 台防火墙沦陷的第二把钥匙（CVSS 6.5·10/16 入 KEV·联邦截止 10/19·PEERSTITCH 行动第二段）

CISA 于 10 月 16 日把 Fortinet CVE-2025-61624 加入 KEV，联邦截止 10 月 19 日——注意距 Fortinet 4 月 14 日发布 FG-IR-26-122 已经过去 185 天。该漏洞是 FortiOS 命令行接口的路径遍历，CWE-22，具备管理员账户且至少有读写权限的攻击者可通过精心构造的 CLI 参数写入或删除任意文件。分数口径有分歧且必须写清：Fortinet 自己给 CVSS v3.1 6.0（AV:L/PR:H，临时分 5.4），NVD 给 6.5（网络向量）。CISA 的记录标注利用为\"活跃\"、技术影响为\"完全\"。6 分意味着按 CVSS 排优先级的团队会把它排在很后面——但 Unit 42 的实战报告恰好证明了这个分数有多误导。攻击链要从两年前说起：2024 年 9 月，某电信托管服务提供商的中央 FortiManager 遭 CVE-2024-47575（FortiJump，CVSS 9.8，免认证）攻击，攻击者在 TCP 541 上注册了一个名为 localhost、序列号 FMG-VMTM23017412 的虚拟设备，随后导出包含 500 多台受管 FortiGate 配置的归档——序列号、公网 IP、路由表、VPN 凭据与加密信任材料全部在内，这些防火墙既保护该运营商自己，也保护它的客户。配置里的口令是可逆密文，Unit 42 通过暴力破解还原了管理员与 SSL/VPN 口令，攻击者从 23.240.77[.]233、47.18.167[.]159 两个跳板建立 VPN 会话进入网络管理区，并经 FortiManager 向下游防火墙推送了针对 HTTP、11 个特定端口（3696–3706）、TFTP(69)、RADIUS(1812/1813)、LDAP(389) 的抓包规则。第二段才是 CVE-2025-61624：auto-script 对象的名称未做净化，含 ../ 的名字可把脚本写到任意路径，攻击者创建名为 ../../../../setup 的对象落 loader，再用 ../../tmp/apache2/conf/md-acme.conf 把 Apache 自带的 ACME 模块改造成反向 Shell（DNS challenge 步骤映射到 Node.js）。随后是 PEERSTITCH——一个用 C 写的 ARM64 内存驻留木马，注入 /bin/miglogd（日志进程）与 /bin/iked（IPsec/VPN 进程），在两者间用已分配内存建隐蔽通道，靠 strstr() 匹配端口标记 8550 与 IP 标记 169.254.0.1 提取会话令牌，再经 /proc 写入 VPN 进程。Unit 42 的原话值得抄下来：它不落盘、不开端口、不发起外连，靠合法进程流量通信，因此对传统终端与网络检测都有抗性，Fortinet 的 Integrity Checker Tool 也查不到，因为它扫的是磁盘文件，而文件从未被改动。攻击前他们还杀掉日志与 syslog 守护进程、执行 diagnose debug crashlog clear、事后自动删除管理员账户与 auto-script 对象，再把恶意 ACME 配置覆写回无害内容。

影响范围

FortiOS 7.6.0 至 7.6.4、7.4.0 至 7.4.9，以及 7.2、7.0、6.4 全部版本；FortiProxy 7.6.0–7.6.4、7.4.0–7.4.11 及 7.2、7.0 全部版本；FortiPAM 1.7.0 及 1.0–1.6（1.8 不受影响）；FortiSwitchManager 7.2.0–7.2.7、7.0.0–7.0.6。修复版本：FortiOS 7.6.5 / 7.4.10，FortiProxy 7.6.5 / 7.4.12，FortiPAM 1.7.1，FortiSwitchManager 7.2.8 / 7.0.7。FortiOS 7.2/7.0/6.4、FortiProxy 7.2/7.0、FortiPAM 1.0–1.6 无同分支修复，只能迁移。FortiSASE 已在 25.4.b 修复，不受影响。

修复建议：先看排期：7.4 与 7.6 分支升到对应修复版即可，但凡在 7.2/7.0/6.4 上的设备，今天就要启动迁移排期，不要指望热修复。无法立刻升级的，Fortinet 在 FortiGuard FMWP 25.120 数据库更新中提供了虚拟补丁 FG-VD-59270.0day。取证先于修复：CISA 的 KEV 条目为这条设了 forensic triage 标记，依据 BOD 26-04，联邦机构不仅要打补丁还必须完成失陷检查；动手前先完整保留管理员审计日志、配置修订历史、命令历史与文件完整性证据。排查动作有两条线——配置侧查 auto-script 对象名里含 ../ 的条目，且必须翻历史修订记录而不只是当前配置，因为攻击者用完就删；进程侧需检查 /bin/miglogd 与 /bin/iked 的内存中是否有异常 RWX 区域或代码里特定偏移处的 NOP 补丁，这一步普通工具做不到，需 Fortinet 支持或专业取证流程介入。配置包里检查是否出现名为 FortiGateCloud 的管理员账号——受害者根本没有 FortiManager Cloud 租户，说明攻击者冒充了管理平台（Unit 42 以中等置信度评估）。最关键的一条动作与补丁无关：把管理平面里保存过的所有凭据、证书和私钥全部轮换。Unit 42 的结论写得很清楚——从管理平台取走的信任材料在轮换之前一直有效，补丁关上的只是门，门里那些钥匙一把没少。同时排查管理平面是否还在运行 2024 年那次入侵的痕迹：FortiJump 之后的两年里，攻击者经由管理平台向下游推送过大量未授权配置，这些推送在配置修订历史里通常留有记录。

严重CVE-2026-108097Critical 19/25

Drupal 双 RCE：官方罕见预警\"补丁公开后数小时到数天内就可能出现利用\"，百万站点必须当紧急事件处理（SA-CORE-2026-014·10/14 发布补丁·至少一条免认证路径）

Drupal 安全团队于 10 月 14 日发布 SA-CORE-2026-014 与 SA-CONTRIB-2026-218，一次修复两条远程代码执行漏洞。CVE-2026-108097 位于 core 的 Field UI 模块，CVE-2026-108099 位于 contrib 的 Entity List 模块（一个用于不依赖 Views 构建实体列表的模块），两条均被 Drupal 安全团队评为 Critical 19/25。真正值得注意的是公告的措辞：项目在披露前就发了预告，公开两个 CVE 编号与受影响版本，并要求管理员预留时间升级，原话是\"利用可能在数小时或数天内被开发出来\"——这种时间线在 CMS 公告里极少见，反映的是攻击者反向补丁构建 exploit 的速度已是小时级而非周级，技术团队建议提前升到各分支最新的 bugfix 版本，把无关的升级问题先排掉。技术原理方面，CVE-2026-108097 出在 Field UI 用 PHP render array 构建管理表格的路径上：table 元素的 pre-render 阶段原本用 call\_user\_func\_array 直接执行行内 #region\_callback 属性里存放的 PHP 可调用对象，虽然 Drupal 自 8.8 起已限制不可信回调，但 table 元素的内部方法绕过了这些检查，直接执行了 pre-render。补丁改为不再执行回调，改为读取行内的 region 值，若值不可识别就回退到 table 的隐藏 region 或第一个 region。两条漏洞都不能仅靠 core 单独触发，需要 contrib 模块或自定义代码把对应功能暴露出来，但 Drupal 明确说明其中至少各有一条路径不需要任何认证——对于一个绝大多数生产部署都堆着一长串 contrib 模块的生态，\"core 单独是安全的\"几乎等于没有安慰。Drupal 全球站点超一百万，政府、高校、非营利机构是主要使用者，这些组织恰好又是补丁节奏最慢的一批。

影响范围

Drupal core 10.x 早于 10.6.19、11.x 早于 11.3.19 或 11.4.10；Entity List 模块早于 3.0.10。10.6.x 之前的 10.x 与 11.3.x 之前的 11.x（含 11.2.x 及以下、10.5.x 及以下，以及 8、9 系列）已 EOL，不会有补丁，必须先升级到受支持分支才能打上修复。Drupal 12 beta2 之前的预发布版同样受影响，但非生产用途，最终 12.0 稳定版已含修复。site 使用 Standard 安装配置（默认含 field\_ui）即默认暴露面。

修复建议：按分支升级 core 到 10.6.19、11.3.19 或 11.4.10，装了 Entity List 的一并升到 3.0.10，先在预发环境验证再上生产。跑在 EOL 分支上的站点今天就该启动迁移，它们不是\"等补丁\"的问题而是\"没有补丁可等\"的问题。无法及时升级的唯一官方缓解措施是卸载核心 Field UI 模块（field\_ui），这会连带失去字段与显示的管理界面，更适合维护态站点而非正在开发的生产站——但它确实能挡掉 108097，注意它不能替代 Entity List 侧的处置。资产盘点不能只数 core 版本号：要按站点列出实际启用的 contrib 模块与自定义代码，逐一确认是否把 Field UI 或 Entity List 的功能暴露给了未认证用户，并确认管理路径不可被匿名访问；这是判断你到底有没有暴露面的唯一方法，公告未披露具体的模块组合与 HTTP 请求，公开面很小。Drupal Steward 只拦截部分已知攻击向量，官方明确说不覆盖全部可能的利用路径，它是减速带不是替代品。另外一句提醒：Drupal 历史上在补丁窗口关闭后被自动化批量扫描是常态，高价值站点通常几小时内就会被摸到，别把\"还没被入侵\"当成结论。

严重CVE-2026-96652CVSS 8.6

Plex2Shell：四条低分漏洞串成免认证 RCE，PoC 公开次日就被拿去挖矿劫持家庭服务器（最高 CVSS v4.0 8.6·10/16 公开 PoC·10/17 已在野利用·CISA 尚未收录 KEV）

研究人员 Zach Main 于 10 月 16 日在自己的博客 zmain.info 公开了完整的 Plex2Shell 漏洞链分析与利用代码（GitHub：code-zm/plex2shell，含 Python exploit 脚本、Linux 与 Windows 载荷源码与检测材料）。这条链由四个 CVE 组成，单独看没有一条分数高：CVE-2026-96652（CVSS v4.0 5.3，player 播放器的 SSRF，只检查 token 是否存在而不验证其有效性）、CVE-2026-96655（5.3，transcoder 的第二处任意主机 SSRF）、CVE-2026-96654（6.9，到达内部插件 API 的 URL 注入）、CVE-2026-96656（8.6，管理员任意文件写，服务器随后会把它当代码加载）。串联起来的效果是：无需任何有效登录即可拿到 root 级的代码执行。链路是 player timeline 端点的免认证 SSRF（任意 token 即可触发）→ 回环接口内部 agent 功能 → 通过构造的回调窃取服务器所有者的管理员令牌 → 操纵 transcoder 偏好把攻击者控制的文件写入 Codecs 目录 → 转码器初始化时加载并执行这些文件，以 Plex 进程权限运行命令。Zach Main 早在 7 月就报告了问题，Plex 在公开前几周就已修复——但修复了不等于用户装了。Plex 早在 9 月 1 日就发出安全公告并邮件提醒 1.43.2 及更早版本必须升级，扫描数据显示仍有超过 36000 台公网暴露的实例未打补丁。真正的转折发生在 10 月 17 日：BoredHackerBlog 的蜜罐在老版本 Plex 上观测到真实利用，用的正是作者 GitHub 上的公开代码，三个来源 IP 分别是 45.194.92.222、91.92.40.202、176.65.139.228，载荷来自 217.60.194.116，包含 XMRig 挖矿程序与名为 myawesomeproxy 的代理工具——攻击者要的不是钱，是家庭宽带 IP，用来当访问企业 VPN 与邮箱的住宅代理。进程名指标为 myawesomeproxy、mylovelyminer、x12345，命令行参数里带 rig 标识、donate level 或域名 proxystream.st；另有非预期的 .so/.dll 落到 Plex Codecs 目录。CISA 目前尚未把这四个漏洞收入 KEV。

影响范围

Plex Media Server 1.43.3.10861 之前的所有版本。需要注意版本号的坑：官方仓库把 1.43.3.10861 标为修复构建，管理员应确认实际安装的精确版本，而不是假定更早的 1.43.3 就已是修复版；Plex 自己也提醒 NAS 用户可能在自己设备厂商的包管理渠道里还看不到该版本，需要手动安装。风险最集中的是直接暴露在互联网的老旧 Linux 安装与 Docker 容器。

修复建议：立刻升级到 1.43.3.10861 及以上，不要把\"9 月就发过公告\"当成自己已安全的理由——这次公开的是可直接运行的 exploit 代码，观测到的武器化速度只有一天。不需要远程访问的，关闭 Remote Access；无论如何不要把 32400 端口直接暴露在公网，做基础网络隔离。升级后做四项检查：主 Plex 二进制有没有异常的子进程、Codecs 目录有没有陌生物件、网络日志有没有匹配上述指标的长连接。已确认被入侵的机器应完整审查用户账户、计划任务与出站流量，从干净基础重装是确认失陷后最可靠的恢复路径。对这类自托管软件的心态问题：Plex 官方不集中管理你家里那台机器，补丁在上游不等于已经装到你的 NAS 上。

严重CVE-2026-15176CVSS 9.2

F5 一次修 NGINX 11 个洞：三个 9.2 全是免认证堆溢出与 use-after-free，ASLR 一旦被关就是 RCE（三个均 CVSS 9.2·10/14 修复·F5 与 Juniper 同周大规模补丁）

F5 于 10 月 14 日为 NGINX Open Source 与 NGINX Plus 发布了 11 个安全问题的修复，其中三条 Critical 值得单独拿出来。CVE-2026-15176 是堆缓冲区溢出，CVSS 9.2：免认证攻击者通过构造 HTTP 请求可触发拒绝服务，在特定配置下（涉及 alias 指令与 $request\_filename 变量）可能执行任意代码。CVE-2026-93479 同为堆缓冲区溢出、同样 9.2，触发条件是 map 指令的正则捕获变量在 map 输出变量之前被引用，或在某些条件下字符串表达式中使用了不可缓存变量，同样免认证、同样经构造 HTTP 请求触发。CVE-2026-97205 则是 ngx\_http\_core\_module 中的 use-after-free，9.2：开启异步文件 I/O（AIO）并处理含 include virtual 命令的 SSI 页面时可造成内存损坏或 worker 进程异常终止。三条都附带同一个限定语——若 ASLR 被禁用或可被绕过，则可实现远程代码执行。这个条件值得认真对待而不是当免责声明：所有现代 Linux 发行版默认开启 ASLR，远程无信息泄露地绕过它很难；但嵌入式设备、加固过（有时配置过头）的容器环境，以及运行老内核的传统系统，ASLR 的强度可能不如预期，攻击者一旦找到这样一个环境，就只需要这一个洞。触发配置虽然有条件，但 alias 指令、map 指令、AIO 与 SSI 都不是生僻配置，在真实生产环境里普遍存在。同期 F5 还修了 CVE-2026-95101 与 CVE-2026-97629 等涉及内存处理与 HTTP/3 请求处理的缺陷，其余问题包括验证绕过、敏感信息读取、请求属性伪造、向代理请求注入数据、无界内存增长以及在认证前访问受保护路径。同周 Juniper Networks 发布了 17 份公告，覆盖 Junos OS 与 Junos OS Evolved 超过 150 个缺陷及 JCNR 的 4 个漏洞，其中约二十来个为 Critical，涉及以 root 权限执行代码/命令、设备完全接管、内核 panic、崩溃、Routing Engine 重启、服务中断，以及一个由 off-by-one 引起的缓冲区溢出。F5 与 Juniper 均未提及这些漏洞存在在野利用。

影响范围

NGINX Plus 与 NGINX Open Source，使用 alias + $request\_filename 组合、使用 map 正则捕获变量且在输出变量之前引用、或在特定条件下于字符串表达式中使用不可缓存变量的部署；CVE-2026-97205 需启用 AIO 并对外提供含 include virtual 的 SSI 页面。Juniper 侧覆盖 Junos OS、Junos OS Evolved 与 Juniper Cloud-Native Router。

修复建议：先清点所有反向代理与自建服务的 NGINX 版本并升级到含 10 月修复的构建，这类补丁的影响面大概是本周所有更新里最广的——因为几乎每家公司都有自己的 NGINX。顺手核对运行环境的 ASLR 状态（cat /proc/sys/kernel/randomize_va_space，2 为开启），对嵌入式设备、特殊加固容器与老旧内核主机重点确认，这一条能把\"理论上\"的条件变成\"实际上\"的防线。同时检查配置中是否真的存在 alias 指令链、map 捕获变量前置引用与 AIO + include virtual 的组合，不存在的可以先降低暴露概率。SSI 属于遗留技术，但大量存放在无人审计的老旧 Web 应用与内部门户里，值得主动清理。Juniper 设备按公告排升级窗口，涉及 Routing Engine 重启的需提前安排维护期与冗余路径。

高危CVE-2026-105740CVSS 9.9

Langflow MCP Stdio 注入：2023 次利用尝试、28 个来源国，低权限账号就能在 AI 编排服务器上执行任意命令（CVSS 9.9·9/19 起持续被利用·修复 1.9.0）

AI 编排平台正在变成新的攻击面，这条是典型样本。Langflow 1.9.0 之前，已通过认证的低权限用户可以保存 MCP Stdio 命令，当随后以 GET /api/v2/mcp/servers?action_count=true 拉取列表时，Langflow 会把保存的命令不做校验直接交给 bash -c 执行，命令以 Langflow 进程权限运行。Previdian 自 9 月 19 日起观测到持续利用尝试，截至 10 月 17 日核实已累计 2023 次，来自 16 个国家的 28 个来源 IP。攻击链很短：攻击者用一个普通低权限账号登录（互联网可达环境下，泄露的口令或创建不当的账号就是入口），添加一个使用 Stdio 传输方式的 MCP 服务器并把执行命令与环境变量保存下来，再去拉一次带 action\_count=true 的列表触发。细节里有一条很容易被漏掉：不带参数的普通列表拉取不会触发执行，这意味着防守方在日志里按「接口被大量调用」来告警会漏掉真正的攻击请求，必须匹配那个特定参数。Previdian 强调了两个观察角度：一是低权限用户在界面上做的事看起来就是正常的 MCP 服务器配置，终端用户界面通常不会给出明显警告；二是管理员侧可见的信号是 MCP Stdio 配置被注册、列表拉取后 bash 进程立即启动、环境变量被修改、以及向未知目的地发起的外联。潜在后果不止拿服务器权限——连接器凭据、AI 模型 API Key、工作流数据乃至同一内网里可进一步发现的东西都在射程内。修复为 1.9.0 及以上。

影响范围

Langflow 1.9.0 之前的部署，尤其是互联网可达的实例。需要低权限账号即可触发，因此默认 LANGFLOW_AUTO_LOGIN=true 一类免凭据配置的部署风险更高。

修复建议：升级到 1.9.0 及以上，并把 MCP Stdio 的使用权限收窄到确有需要的管理员，不要给普通用户。运行 Langflow 的进程本身应以低权限、最好沙箱化的方式运行——这条对本产品尤其重要，因为它天然会调用外部命令与连接外部服务，权限边界就是最后的兜底。减少不必要的互联网暴露、清理共享账号与长期 API Key。日志侧把检索条件明确成 GET /api/v2/mcp/servers?action_count=true，并关联检查紧随其后的 bash 子进程启动记录、环境变量变更与未知目的地外联，而不是泛泛地看接口调用量。

紧急提醒

本期最高优先级是 CVE-2026-102764，因为它同时踩中了三个最坏的组合：零日期长达七周（8 月 29 日利用、10 月 15 日公告），远程支持平台本身具备设计上的特权（它的工作就是代理别人去连所有终端），而攻击者的目标正是这些被托管的凭据——一台被拿下的 Remote Support，等于把下游所有系统的钥匙一次性交出去。更麻烦的是它会主动销毁证据：本地日志被清、工具被删，设备上看似干净。联邦截止日就是今天（10 月 19 日），但即便你不受 BOD 约束，今天也应该是同一个动作。

排在第二位的是把 CVE-2025-61624 当成一次\"架构性提醒\"而不是一个 6 分漏洞来处理。这条链的关键不是路径遍历本身，而是2024 年被打穿的管理平面把 500 多台防火墙的信任材料送了出去，两年后这些凭据依然有效。攻击者选择公开可用的那条旧 FortiManager 漏洞作为起点，也解释了为什么这条 6.0 分的洞会被用到今天。凡是以托管服务形式管理他人防火墙的（MSP、云服务商、托管机房），那次入侵的影响面覆盖客户网络，而 Unit 42 明确说了他们的调查只覆盖了供应商自身环境、没往下游查——真实暴露面可能至今没数清。

第三位是 Drupal。它给出的\"数小时到数天\"预警在 CMS 公告里几乎绝迹，19/25 的自评配上至少一条免认证路径，加上百万站点里扎堆的政府与高校用户，这个组合的处置窗口比 CISA 的截止日更短。

其余三条的共同点是\"公开代码已经可用\"。Plex2Shell 的 PoC 在 GitHub 上放着，从发布到在野利用只隔了一天；NGINX 三条 9.2 只要环境里 ASLR 不够硬就是 RCE；Langflow 用的是普通账号。任何\"我们评估了一下风险不大\"的判断，在这些案例上都不成立。

处置建议

① 今天先做 BeyondTrust。登录每台自托管 Remote Support / PRA 设备的 /appliance 接口，核对版本与 BT26-05-RS 是否已安装（< 24.3.1 先升级才装得上），确认设备是否订阅自动更新，未开的立即手动打。补丁后按行为排查：无法对应管理员或工单的特权会话、web 目录下的可疑脚本、Web 服务账户派生 shell、对 Jump Items/Teams 的未授权变更、单次会话内起止的日志转发中断。重点查 /usr/bin/dbus-authd 是否为 /bin/sh 的 SUID 副本、haproxy.conf 是否有异常修改。发现失陷立即隔离 → 先做虚拟快照/物理取证镜像 → 重建后打补丁 → 轮换该设备存储或注入过的全部凭据、撤销所有活动支持会话、复查特权账号的新增 MFA 注册。SaaS 客户无需动作。

② Fortinet 侧先取证再修复。7.4 升 7.4.10、7.6 升 7.6.5、FortiProxy 7.4 升 7.4.12 / 7.6 升 7.6.5、FortiPAM 升 1.7.1、FortiSwitchManager 升 7.0.7 / 7.2.8；跑在 7.2/7.0/6.4、FortiProxy 7.2/7.0、FortiPAM 1.0–1.6 的设备今天启动迁移排期。来不及的先上虚拟补丁 FG-VD-59270.0day（FMWP 25.120）。动手前完整保留管理员审计日志、配置修订历史、命令历史与文件完整性证据；排查 auto-script 对象名含 ../ 的条目（必须翻历史修订而非只看当前配置，攻击者用完即删）、异常 FortiGateCloud 管理员账号、以及 /bin/miglogd 与 /bin/iked 内存中的异常 RWX 区域（这一步需 Fortinet 支持介入）。无论是否发现异常，都要把管理平面保存过的所有凭据、证书、私钥全部轮换——被拿走的信任材料在轮换前一直有效。同时回溯 2024 年 9 月以来的配置推送记录，看是否有未授权的抓包策略或管理员变更。

③ Drupal 按紧急事件处理：升级 core 到 10.6.19 / 11.3.19 / 11.4.10，Entity List 到 3.0.10；跑 EOL 分支（10.5.x 及以下、11.2.x 及以下、8/9 系列）的站点今天启动分支迁移，不能等。无法及时升级的卸载 field\_ui 模块作为临时缓解（会失去字段管理界面，且不能替代 Entity List 侧处置）。按站点逐一盘点启用的 contrib 模块与自定义代码，确认 Field UI / Entity List 功能是否暴露给匿名用户、管理路径是否可达；不要依赖 Drupal Steward，它不覆盖全部利用路径。升级后检查 web 进程异常子进程与新建文件。

④ NGINX 与 Juniper 本周内排完：清点所有反向代理与自建服务的 NGINX 版本，升级到含 10 月修复的构建；同时 cat /proc/sys/kernel/randomize_va_space 确认 ASLR 为 2，重点确认嵌入式设备、加固容器与老内核主机；检查配置中是否存在 alias + $request\_filename、map 正则捕获变量前置引用、AIO + include virtual 组合，并清理遗留 SSI 页面。Juniper 设备按 17 份公告排升级，涉及 Routing Engine 重启的提前安排维护期与冗余路径。

⑤ Plex 立即升级并自证：升到 1.43.3.10861 及以上（注意精确版本号，1.43.3 不等于已修复），NAS 用户确认包管理渠道是否已推送；不需远程访问的关闭 Remote Access，不把 32400 暴露公网；升级后查主进程异常子进程、Codecs 目录陌生物件、myawesomeproxy / mylovelyminer / x12345 进程与 proxystream.st 相关连接，并封禁 45.194.92.222、91.92.40.202、176.65.139.228、217.60.194.116；已确认失陷的从干净基础重装并审查用户账户与计划任务。

⑥ Langflow 与 M365 身份侧：Langflow 升到 1.9.0 及以上，MCP Stdio 权限收给管理员，进程以低权限沙箱方式运行，减少互联网暴露、清理共享账号与长期 API Key；日志检索条件明确成 GET /api/v2/mcp/servers?action_count=true 及其后紧随的 bash 启动。另请顺带自查：是否有远程支持/MSP 类供应商在管理你们的系统，其凭据与信任材料是否轮换过——本周三条核心漏洞里有两条的起点都是\"被托管的凭据\"。

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