2026年10月 GitLab・Cisco ASA/FTD・Ivanti Connect Secure 安全修复汇总：影响范围与各环境的处置步骤

要点

• Ivanti Connect Secure：升级到 25.1.1.3 / 22.8R2.6 / 25.1.3.x。已确认有攻击串联3个漏洞拿到 root 权限，最初的修复版不够
• GitLab：升级到 19.5.3 / 19.4.5 / 19.3.7。CVE-2026-97229 已列入 KEV。停在 19.4.2 等版本的话，CVE-2026-110264 仍未修复
• Cisco ASA / FTD：可让 SSL VPN 设备重启的 CVE-2026-76418 正被利用，9月的版本修不了。请升级到 ASA 9.20.4.50、FTD 7.6.7 等
• KEV 的处置期限（针对美国联邦机构）：GitLab 和 Cisco 为11月1日，Ivanti 为10月16日（已过）、11月2日和11月13日。请先升级暴露在互联网上的设备
• 升级并不能清除已经入侵的攻击者。Ivanti 和 GitLab 请排查入侵痕迹，有可疑迹象就更换凭据、证书和令牌

关于本文

本文依据截至2026年10月31日（日本时间）的一手资料整理而成，包括 Ivanti、GitLab、Cisco 的官方公告，美国 CISA 的“已知被利用漏洞目录（KEV）”（目录版本 2026.10.30），CVE.org、NVD、JPCERT/CC，以及调查攻击事件的 Volexity 的报告。情况随时在变，动手前请以文末的官方链接为准。

KEV 和各厂商公告中的日期均为发布方的日期（美国时间等）。KEV 的处置期限是美国对联邦机构的指令（BOD 26-04）规定的期限，但可以作为排优先级的参考。正文按处置期限从早到晚的顺序，依次介绍 Ivanti、GitLab、Cisco。

不同机构给出的严重程度评分并不一致，文中都会注明是哪一家的评分。CISA 在 CVE 记录中附加的 SSVC 评估如果为“已被利用”，就表示已确认存在实际利用。

在日本国内，截至10月31日，JPCERT/CC 的安全警报（注意喚起）和 IPA 的紧急信息都没有针对这3个产品发布。JPCERT/CC 的周报提到了 GitLab 和 Ivanti。漏洞数据库 JVN iPedia 和 MyJVN 已于10月30日发布公告暂停服务，预计11月恢复。

第一步：先确认自己是否受影响

Ivanti Connect Secure

• 登录管理界面后，在首先显示的“System > Status”页面确认版本（通过 SNMP 可读取 MIB 中的 productVersion）
• 受影响：25.1.0.0～25.1.1.2、25.1.2.0～25.1.2.2、22.8R2～22.8R2.5。全部修复：25.1.1.3、22.8R2.6（Ivanti 称 25.1.3.0、25.1.3.1 也“不包含此漏洞”）
• 最初的修复版 25.1.1.2 和 22.8R2.5 只修复了 CVE-2026-104935，还需要继续升级
• 22.7 系列及更早版本不受影响（Ivanti 的说法）。但 22.7 系列将于2027年1月31日结束支持
• 漏洞扫描器的注意事项：CVE-2026-104935 的 CVE 记录没有把 25.1.1.2 列为不受影响，因此使用 CVE.org 数据的产品可能会把 25.1.1.2 显示为“受影响”

GitLab

• 确认版本：Linux 安装包用 sudo gitlab-rake gitlab:env:info，Docker 在容器内执行（例：docker exec -it gitlab gitlab-rake gitlab:env:info），源码安装用 bundle exec rake gitlab:env:info RAILS_ENV=production。在网页界面中，左下角的“Help > Help”会显示版本
• Helm：把 helm list -n <命名空间> 显示的 Chart 版本，对照 GitLab 的版本对应表换算（例：Chart 10.5.4 = GitLab 19.5.3）
• 19.5.3 / 19.4.5 / 19.3.7：已包含10月的全部修复
• 19.5.1 / 19.4.3 / 19.3.6：CVE-2026-97229 和 CVE-2026-110264 已修复，10月29日的 CVE-2026-111943 尚未处理
• 19.5.0、19.4.2、19.3.5、19.3.4、19.2.8：CVE-2026-110264 未修复。19.4.1 及更早的 19.4 系列、19.3.4 及更早的 19.3 系列、19.2.7 及更早的 19.2 系列，CVE-2026-97229 也未修复
• 19.2 系列～18.11 系列：延长支持的修复版 19.2.10 / 19.1.10 / 19.0.11 / 18.11.14 修不了10月21日的另外11项，其中 19.1.10 / 19.0.11 / 18.11.14 还缺少10月12日的大部分修复（如 CVE-2026-14814）。18.10 及更早版本没有修复版（7.0～18.10 的所有版本都受 CVE-2026-110264 影响）
• GitLab Runner 用 gitlab-runner --version 确认（所需版本见后文）

Cisco ASA / FTD

• ASA：show version | include Version。版本也可能显示为 9.20(4)50 这样的格式，它等同于 9.20.4.50
• FTD：用 CLI 的 show version（看“Threat Defense ... Version”那一行），或在 FMC 的“Devices > Device Management”中确认。show version system 显示的 ASA 版本不是 FTD 的版本
• 配置：用 show running-config webvpn 确认启用了 SSL VPN 的接口以及有无 tunnel-group-list enable，用 show running-config tunnel-group | include tunnel-group|secondary-authentication-server-group 确认哪些隧道组使用了二次认证。FTD 请在 FMC 的“Devices > VPN > Remote Access”或 FDM 的“Remote Access VPN”中确认
• 不要只比较版本号大小。ASA 的 9.18.4.135、9.20.4.235、9.23.1.195、9.24.1.155 是热修复版，编号比修复版大，却被列为受影响。请把准确的版本和机型输入 Cisco Software Checker 确认

Ivanti Connect Secure：CVE-2026-104935 等3个漏洞的串联攻击

发生了什么

Ivanti 于2026年10月13日在 Connect Secure 的安全公告（Ivanti Hub 文章 000109571）中公布了 CVE-2026-104935 的修复，并在10月29日的更新中追加了2个相关漏洞。Ivanti 已确认，有少数客户因这3个漏洞被串联利用而实际受害。Ivanti 没有公布临时规避方法。

• CVE-2026-104935：通过伪造绕过认证（CWE-290），未经认证的远程攻击者可以执行任意命令。Ivanti（CVE 编号机构）的评分为 CVSS 8.6（CVE 记录为 v3.1，公告中标注为 v3.0）。CISA 的 SSVC 评估为“已被利用、可自动化、技术影响为全面”
• CVE-2026-111357：关键功能缺少认证，已登录的本地攻击者可以提升权限。Ivanti 的评分为 CVSS 3.1 的 8.8。CVE 记录（由 MITRE 编号）则为 7.0，受影响版本只列了 22.8R2.4
• CVE-2026-118527：使用可预测的文件名（CWE-340），已登录的远程攻击者可以把任意内容上传到磁盘上的已知位置。Ivanti 的评分为 CVSS 4.3（v3.0）。截至10月31日，该编号在 CVE.org 上仍为预留状态（RESERVED），NVD 也尚未收录
• Ivanti 表示，CVE-2026-104935 的一部分是其内部发现的，已在7月的 25.1.3.0 中修复，在向旧系列移植修复的过程中开始出现利用
• 据调查此事的 Volexity 称，攻击始于10月3日（攻击者代号 UTA0576），被入侵的是当时 22.8 系列的最新版、已打全补丁的 22.8R2.4（Build 19097）。入侵后，攻击者利用 Active Directory 的服务账户在 AD 中搜索 LAPS 密码和 BitLocker 恢复密钥（结果被保存为文件），还进行了密码喷洒攻击和网络窃听
• KEV：CVE-2026-104935 于10月13日列入（期限10月16日）。CVE-2026-111357 和 CVE-2026-118527 于10月30日列入，期限分别为11月2日和11月13日。CVE-2026-104935 和 CVE-2026-111357 附带了排查是否被入侵（取证分诊）的要求
• CISA 于10月13日发布警报，并在10月30日修订为涵盖3个漏洞的内容。JPCERT/CC 在10月21日的周报中介绍了 CVE-2026-104935 及其被利用的情况

受影响和不受影响的产品

• 对于 25.1.3.0 及以后的版本，Ivanti 表示“不包含此漏洞”。但 Ivanti 并没有明确把 25.1.3.x 列为 CVE-2026-111357 / 118527 的修复版本
• Pulse Connect Secure 9.1x 已于2024年12月31日结束支持，本次公告没有提及。它不会再有代码修复，需要迁移
• Ivanti Policy Secure、Neurons for ZTA 网关、Neurons for Secure Access、Ivanti Secure Access Client，在本次公告和 Ivanti 10月安全更新的博客中都没有出现
• Linux 发行版、Docker、Homebrew、winget 上都没有需要更新的东西，需要升级的是设备本身

处置：各版本和机型的修复版本与步骤

通用流程是“备份配置 → 完整性检查（ICT）→ 升级 → 确认版本 → 再跑一次 ICT”。

1. 备份配置（二进制格式的配置备份，见 Ivanti KB44759）
2. 升级前先运行 ICT，检查有无入侵迹象（见后文）
3. 从 Ivanti License System（ILS）下载修复版的安装包
4. 在“Maintenance > System > Upgrade/Downgrade”的“Install Service Package”中安装。不要勾选“Deletes”，否则会清除全部配置。安装完成后设备会重启
5. 在“System > Status”中确认版本。集群环境要在所有节点上确认

• 25.1.0.x / 25.1.1.x：升级到 25.1.1.3。Ivanti 明确写出的是“ISA6000 或 ISA8000 上的 25.1.1.1 升级到 25.1.1.3”，没有提到同一系列的虚拟设备，使用前请先向 Ivanti 确认
• 25.1.2.x（ISA-6500 / ISA-8500 专用版本）：先升级到 25.1.3.0，再升级到 25.1.3.1。只能从 25.1.3.0 升级到 25.1.3.1
• 25.1.3.0 / 25.1.3.1：Ivanti 表示“不包含此漏洞”（如前所述，并未逐个 CVE 写明）。Ivanti 建议使用最新的 25.1.3.1
• 22.8R2.x：Ivanti 建议迁移到 25.1.1.3 或更高版本。暂时无法迁移的，升级到 22.8R2.6（可解决本次全部漏洞）。22.8 系列只是通往 25.1 系列的临时过渡版本，将于2027年1月31日结束支持。从 22.8R2 到 25.x 不能以集群方式直接升级，需要先拆散集群，逐个节点升级后再重新组建
• 迁移到 25.1.3.x 时的机型限制：需要 ISA4500 / ISA6500 / ISA8500，或用 25.1.3.0 模板新建的虚拟机或云实例。ISA-6000 / ISA-8000 和现有的虚拟设备不能原地升级，只能迁移配置。虚拟设备需要 vTPM
• Ivanti 的兼容性指南（10月22日更新）没有列出可升级到 25.1.1.3 和 22.8R2.6 的起始版本，截至10月31日这些版本的发行说明也未公开。动手前请在 Ivanti 支持门户中确认

怀疑被入侵时（只靠 ICT 不够）

• Ivanti 建议定期运行内置的完整性检查工具（ICT）。设置位置在“System > Configuration > Security > Miscellaneous”，事件日志中出现 SYS32039（新文件）或 SYS32040（不一致的文件）时要警惕。出现 SYS32039 时，Ivanti 要求把设备从网络上断开，并把系统快照发给技术支持
• 但本次攻击可能无法被 ICT 发现。Volexity 报告称，篡改只发生在内存中且事后被还原，ICT 什么也没检测到。CISA 也表示需要做网络和内存取证。内存中的证据会因重启或初始化而丢失，如需调查，请考虑先保全证据（这不是 CISA 或 Ivanti 明确给出的步骤）
• Volexity 公布的痕迹：大量访问 /dana-na/auth/url_default/welcome.cgi 的请求，带有 X-DSCGI-PATH 请求头的请求（尤其是 URL 路径与请求头的值不一致的），隐藏目录 /data/.icscap/，部分日志被删除，以及攻击来源 IP 地址 108.165.147[.]64。Volexity 还提醒，攻击者可能会找到其他路径
• Volexity 的 YARA 规则可以这样用于收集到的日志或内存镜像：curl -sLO 'https://raw.githubusercontent.com/volexity/threat-intel/main/2026/2026-10-13%20Ivanti/rules.yar' && yara -r rules.yar <收集的文件路径>
• CISA 的恢复步骤：（1）备份配置（2）恢复出厂设置并升级到最新版（虚拟机和云实例重建后升级）（3）恢复配置（4）更换域账户、管理员和本地账户的密码，吊销并重新签发设备上保存的证书，更换 API 密钥和许可证服务器的凭据。硬件设备的出厂重置要通过串口控制台进行（Ivanti KB22964）
• Ivanti 的恢复步骤文档（Recovery-Steps）要求在隔离环境中操作，升级完成之前不要接入互联网。但该文档仍把初始化后的版本写为 22.7R2.5（8月26日更新），请改用本次的修复版本
• 从 Volexity 报告的访问对象来看，LAPS 密码和 BitLocker 恢复密钥也应考虑更换（这是厂商步骤之外的补充检查）。攻击者使用的、设备上配置的 AD 服务账户，在 Ivanti 的恢复步骤中也属于认证服务器配置所用的服务账户，需要更换密码

暂时无法升级时

• Ivanti 没有公布临时规避方法或通过配置缓解的办法，升级到修复版是唯一的处置方式
• Volexity 建议监控访问 welcome.cgi 的请求量和 X-DSCGI-PATH 请求头，但这只是检测手段，并不能阻止攻击
• 攻击来源 IP 是9月30日～10月7日运行 OpenVPN 服务器的一台 VPS 的地址，封锁它的效果有限，主要用于排查历史日志

GitLab：CVE-2026-97229、CVE-2026-110264 与10月的3次补丁发布

发生了什么

GitLab 的安全修复只覆盖最新的和之前的2个月度版本（目前为 19.5 / 19.4 / 19.3）。面向 19.2 及更早系列的版本属于例外移植，只包含部分修复。

• 10月12日：19.4.2 / 19.3.5 / 19.2.8 修复了包括 CVE-2026-97229 在内的24项。19.3 系列先发布的 19.3.4 有缺陷，当天被 19.3.5 取代。19.3.4 受 CVE-2026-97229 影响
• 10月21日：19.5.1 / 19.4.3 / 19.3.6 修复了包括 CVE-2026-110264 在内的12项。其中只有 CVE-2026-110264 被移植到了 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13
• 10月29日：19.5.3 / 19.4.5 / 19.3.7，以及延长支持的 19.2.10 / 19.1.10 / 19.0.11 / 18.11.14。这次是针对 CVE-2026-111943，撤销对8张已泄露的 eMudhra 中间 CA 证书的信任，GitLab Runner 和 AI Gateway 也需要更新
• 19.5.2 和 19.4.4 是跳过的版本号，既没有安装包也没有镜像。19.5.0（10月15日）和10月12日的各版本都没有修复 CVE-2026-110264

主要修复的漏洞

• CVE-2026-97229（10月12日）：编译 CI/CD 正则表达式的处理（Ruby 的正则引擎 Onigmo）中的整数溢出（CWE-190）。攻击者可在 GitLab 服务器上以 git 用户身份执行代码，进而窃取 gitlab-secrets.json、CI/CD 变量、Runner 令牌和访问令牌，并读写所有仓库。入口包括 CI Lint API、流水线编辑器使用的 GraphQL，以及对推送的 .gitlab-ci.yml 的处理。受影响的是 19.2～19.4 系列中早于 19.2.8 / 19.3.5 / 19.4.2 的版本
• 严重程度：GitLab（CVE 编号机构）的评分为 CVSS 3.1 的 10.0。Red Hat 评为 Critical（9.8），Amazon Linux 评为 Important（8.1）。CISA 的 SSVC 评估为“已被利用、可自动化、技术影响为全面”
• 利用情况：CISA 于10月29日将其列入 KEV（期限11月1日，附带排查是否被入侵的要求）。JPCERT/CC 在10月21日的周报中表示，已确认概念验证代码（PoC）被公开。Metasploit 的攻击模块于10月30日被合并，前提是拥有可以向公开项目推送代码的账户。截至10月31日，GitLab 的各篇发布说明都没有提到被利用或 KEV
• GitLab 的检测规则说明，CVE-2026-97229 绕过了9月23日的 19.4.1 对 CVE-2026-93577（GitLab 评分 9.9）所做的不完整修复
• CVE-2026-110264（10月21日）：显示 Org-mode（.org）文件时使用的 org-ruby 0.9.12，在根据文件中的关键字拼装正则表达式时，会触发 Onigmo 的越界写入。只要有一个放有攻击用 .org 文件的公开项目，就能在无需认证的情况下发起攻击。受影响的是 7.0 以后、早于 18.11.13 / 19.0.10 / 19.1.9 / 19.2.9 / 19.3.6 / 19.4.3 / 19.5.1 的所有版本。GitLab 的评分为 CVSS 10.0，Red Hat 评为 Critical（9.8）。截至10月31日尚未列入 KEV，SSVC 评估为“无被利用证据”
• CVE-2026-111943（10月29日）：在 Go 的 crypto/x509 中加入拒绝已泄露的 eMudhra 中间 CA 证书的机制。由 Go 编号，CVSS 只有 CISA 给出的参考值 6.8。GitLab 已把 CA 证书包更新到10月20日版
• 其他修复：10月21日的另外11项中有 OmniAuth 到 LDAP 自动关联时的认证缺陷（CVE-2026-15723，8.2）等，10月12日的另外23项中有 CVE-2026-92883（8.7）等。以上均为 GitLab 的评分，截至10月31日均未列入 KEV，也没有被利用的证据
• 9月的 KEV：提交 API 的路径遍历漏洞 CVE-2026-85706（GitLab 评分 10.0）也已于9月11日列入 KEV。18.7 及以后、早于 19.3.2 / 19.2.6 / 19.1.8 / 19.0.9 / 18.11.12 的版本，这个漏洞也没有修复

GitLab.com、Dedicated 和自行运维的情况

• GitLab.com 已应用10月的全部修复，GitLab Dedicated 在 19.4.3-internal0 及以后无需处理
• 在 VPS、云服务器、公司内部服务器上自行运行的 GitLab，需要用户自己升级。没有可直接在 Windows、macOS 上运行的 GitLab 服务器，请按 Docker 或 Linux 虚拟机的步骤升级
• 中国的极狐 GitLab（gitlab-jh），截至10月31日只发布到相当于上游 19.5.1 / 19.4.3 / 19.3.6 等的版本，相当于10月29日修复的版本尚未提供

处置：各安装方式的修复版本和步骤

通用流程是“备份 → 升级到本系列的最新版 → 确认服务已重启 → 确认版本”。GitLab 的发布说明中没有升级以外的规避方法。

1. 19.3～19.5 系列，升级到同系列的 19.3.7 / 19.4.5 / 19.5.3。19.2 及更早的系列，请计划迁移到 19.3.7 或更高版本
2. 不要跳过必经版本（升级停靠点）。GitLab 18 的必经版本是 18.2、18.5、18.8、18.11，GitLab 19 是 19.2、19.5。只有从 19.2.x 及以后才能直接升级到 19.5.3（Upgrade Path 工具）
3. 做好备份。Linux 安装包在升级前会自动备份数据库（存在 /etc/gitlab/skip-auto-backup 时会跳过），但 GitLab 建议另外做一份完整备份
4. 19.5.3 和 19.4.5 包含数据库迁移，单机部署会有停机时间
5. 不要指定比当前更低的版本。包管理器会照指定把版本降下来（例：在 19.4.x 的主机上指定 19.3.7）。如果本文发布后又出了新的补丁版，请用新的版本

• Debian / Ubuntu：sudo apt update && sudo apt install gitlab-ee=19.5.3-ee.0（留在 19.4 系列用 gitlab-ee=19.4.5-ee.0，19.3 系列用 gitlab-ee=19.3.7-ee.0。CE 版像 gitlab-ce=19.5.3-ce.0 这样把结尾改成 -ce.0）。Ubuntu 20.04 最后支持的是 18.11 系列，最高只能到 gitlab-ee=18.11.14-ee.0。18.11.14 缺少10月21日的另外11项和10月12日的大部分修复，请计划迁移到更新的 Ubuntu
• RHEL / AlmaLinux / Oracle Linux：sudo dnf install gitlab-ee-19.5.3-ee.0.el9（8 系列把结尾改为 .el8，10 系列改为 .el10）
• Amazon Linux：2023 用 sudo dnf install gitlab-ee-19.5.3-ee.0.amazon2023。Amazon Linux 2 最高只能到 sudo yum install gitlab-ee-19.2.10-ee.0.amazon2，修不了10月21日的另外11项，请计划迁移到 2023
• SLES / openSUSE Leap 15.6：sudo zypper install gitlab-ee=19.5.3-ee.0.sles15
• 官方 Docker 镜像：gitlab/gitlab-ee:19.5.3-ee.0（CE 版为 gitlab/gitlab-ce:19.5.3-ce.0）。Compose 改写 docker-compose.yml 中的标签后执行 docker compose pull && docker compose up -d。用 docker run 的，先执行 sudo docker stop gitlab && sudo docker rm gitlab，再 pull 新镜像，用与之前相同的参数和数据卷重建容器。latest 指向 19.5.3，但没有按系列区分的标签，生产环境请使用写明版本的标签
• Helm Chart：Chart 的版本号与 GitLab 的版本号不一致（10.5.4 = 19.5.3，10.4.6 = 19.4.5，10.3.9 = 19.3.7）。执行 helm repo update 和 helm get values gitlab > gitlab.yaml 后，需要停机的方式用 helm upgrade gitlab gitlab/gitlab --version 10.5.4 -f gitlab.yaml --set gitlab.migrations.enabled=true。不停机升级请按 GitLab Chart 的步骤操作
• Geo（多站点）：先升级主站点，再升级从站点。/etc/gitlab/gitlab-secrets.json 必须在所有节点上保持一致。最后用 sudo gitlab-rake gitlab:geo:check 确认
• 使用系统 Ruby 的 GitLab：官方的 Linux 安装包和镜像自带经 GitLab 修补的 Ruby，但源码安装、Arch Linux、FreeBSD、NixOS 等使用系统的 Ruby，Ruby 也需要 3.3.13 / 3.4.12 / 4.0.9 或更高版本。Arch 执行 sudo pacman -Syu 即可同时装上 gitlab 19.5.3-1 和 ruby 3.4.12-1，但截至10月31日，FreeBSD ports 和 NixOS unstable 的 Ruby 仍是修复前的版本
• 社区制作的 sameersbn/gitlab 镜像：10月30日的标签（19.5.3 等）使用 Ruby 3.3.13，但10月22～26日的标签仍是 Ruby 3.3.12。可用 docker exec <容器名> ruby -v 确认
• Raspberry Pi OS（32位）：GitLab 已在 17.11 系列停止提供，CVE-2026-110264 不会修复。请迁移到64位系统和 Debian 的 arm64 安装包

GitLab Runner 和 AI Gateway（需与 GitLab 本体分开升级）

升级 GitLab 本体并不会升级 Runner 和 AI Gateway。Runner 不受正则表达式漏洞影响，需要升级是为了 CVE-2026-111943（eMudhra 证书）。

• Runner：19.5.1 或更高（10月28日还发布了 19.5.2）。GitLab 指定的是 19.5.1。19.4.3 和 19.3.5 也带有已修复的 Go，但 GitLab 没有明确说这样就足够（19.4.1 和 19.3.3 用的是修复前的 Go）
• Debian / Ubuntu 用 sudo apt update && sudo apt install gitlab-runner，RHEL 系用 sudo yum update gitlab-runner（不带参数的 sudo yum update 会在不指定版本的情况下升级包括同一台服务器上 GitLab 本体在内的所有软件包），会装上最新版。如果要固定版本（gitlab-runner=<版本>-1 gitlab-runner-helper-images=<版本>-1），不要指定比当前更低的版本（例：在 19.5.2 的主机上指定 19.5.1-1 会降级）
• Docker 执行 docker pull gitlab/gitlab-runner:v19.5.2 后，删除旧容器并用相同的配置卷重新启动。Windows、macOS 替换官方二进制文件，Homebrew 用 brew upgrade gitlab-runner。Alpine 的软件包（v3.22 为 18.6.1）版本太旧，请使用 GitLab 官方的版本
• CI/CD 作业镜像：自带 ca-certificates 的镜像需要重建（基于 Alpine 的用 RUN apk upgrade --no-cache ca-certificates 升级到 20261020-r0）
• AI Gateway（Duo Self-Hosted）：需要 18.11.8 / 19.0.13 / 19.1.9 / 19.2.5 / 19.3.3 / 19.4.3 / 19.5.3 或更高版本。GitLab 要求使用与 GitLab 版本对应的最新 self-hosted-vX.Y.*-ee 标签，截至10月31日最新的是 self-hosted-v19.5.4-ee 等。截至10月31日，18.11.8 和 19.1.9 的镜像尚未发布

使用 Ruby 正则引擎 Onigmo 的其他软件

CVE-2026-89078、CVE-2026-93577、CVE-2026-97229、CVE-2026-110264 的根本原因是 Ruby 内置的 Onigmo 的缺陷。Ruby 于10月23日发布 4.0.9 / 3.4.12 / 3.3.13，全部修复了这些问题。CISA 也在 KEV 的备注中警告，GitLab 以外的产品也可能受影响。

• 受影响的是用外部传入的字符串拼装正则表达式（Regexp.new、Regexp.union 等）的应用。在升级之前，请停止这类处理
• Ruby 没有申请自己的 CVE 编号，建议用 GitLab 的 CVE 编号跟踪。Regexp.timeout 防不住，限制正则长度也不是可靠的对策。Ruby 3.2 已于2026年4月1日结束支持，不会修复
• 已修复：官方 Docker 镜像 ruby:4.0.9 / ruby:3.4.12 / ruby:3.3.13，Homebrew（brew upgrade ruby），RubyInstaller 4.0.9-1 / 3.4.12-1 / 3.3.13-1，ruby-build v20261023，Fedora 46（ruby-4.0.9-41.fc46），Alpine edge 和 v3.22（3.4.12-r0），Arch，openSUSE Tumbleweed
• 截至10月31日尚未修复：Debian（bookworm 的 ruby3.1、trixie 的 ruby3.3），RHEL 的各个 ruby 流，Amazon Linux（AL2023 的 ruby3.2 不打算修复），SLES 15 SP7 / SLES 16。Fedora 43～45 只在 updates-testing 中提供
• 升级后，请重启 Puma、Sidekiq 等所有常驻的 Ruby 进程

暂时无法升级时的临时措施（均不完整）

以下是 GitLab 安全团队在检测规则中列出的、在升级前降低风险的措施。

• CVE-2026-97229：限制谁能创建账户和个人访问令牌（例：关闭任何人都能注册的设置）。这只能减少可发起攻击的人，并不能修复漏洞
• CVE-2026-110264：减少公开项目，删除包含攻击用 .org 文件的项目或改为私有。已登录用户的攻击路径仍然存在
• 用 VPN 或来源限制，让 GitLab 不能从互联网直接访问。这不是 GitLab 给出的规避方法，但 CISA 的 BOD 26-04 把与互联网断开视为有效的缓解措施

升级后的确认与入侵排查

• 用 sudo gitlab-ctl status 确认 puma、sidekiq、gitlab-workhorse 的运行时间是从升级后开始计算的，如果还是旧的就执行 sudo gitlab-ctl restart。Docker 用 docker ps --format '{{.Names}} {{.Image}}' 确认没有残留使用旧标签的容器
• GitLab 针对 CVE-2026-97229 公布了6条检测规则，针对 CVE-2026-110264 公布了2条。例如，Workhorse 对 CI Lint 或 GraphQL 返回 502 的记录可以用 grep -E '"uri":"[^"]*(ci/lint|/api/graphql)' /var/log/gitlab/gitlab-workhorse/current* | grep -E '"status":502|badgateway' 查找，工作进程的异常退出可以用 grep -B1 -A20 '\[BUG\]' /var/log/gitlab/puma/puma_stderr.log* 查找（压缩过的日志用 zgrep）
• 日志里什么都没有，也不能断定没有被利用。GitLab 表示，成功的攻击可能不留明显痕迹
• 如果发现代码执行的迹象，就按已被入侵处理：更换 gitlab-secrets.json 中的机密信息、所有 CI/CD 变量、Runner 令牌和访问令牌，并保全日志。还要检查 git 用户在 /tmp 中新建的文件、意外的子进程、对外连接，以及 crontab 和 SSH 密钥的变化

Cisco ASA / FTD：CVE-2026-76418（10月28日临时发布）

发生了什么

Cisco 于2026年10月28日（GMT）在例行发布日之外临时发布了安全公告（cisco-sa-asaftd-tunnel-dos-s6mgkb75）。对象是 Secure Firewall ASA 和 Secure Firewall Threat Defense（FTD）的远程访问 SSL VPN。

• 影响：未经认证的远程攻击者可以让设备重启，造成服务中断（空指针引用，CWE-690）。不需要成功登录 VPN
• 严重程度：Cisco PSIRT（CVE 编号机构）的评分为 CVSS 3.1 的 8.6（Cisco 的严重性评级为 High）。CISA 的 SSVC 评估为“已被利用、可自动化、技术影响为部分”
• 利用情况：Cisco PSIRT 表示已于2026年10月发现实际利用，但没有公布入侵痕迹（IoC）或 Snort 规则。CISA 于10月29日将其列入 KEV（期限11月1日）
• 9月的修复版修不了。8月的 CVE-2026-20349（同为 VPN 服务中断，已列入 KEV）的修复版，以及9月的加固版本（ASA 9.22.3.26、FTD 7.6.6 等），全部在本次的受影响范围内
• Cisco 发布了日文参考译文（以英文版为准）。截至10月31日，JPCERT/CC 的安全警报和 IPA 的紧急信息都没有发布

受影响的配置和产品

• 启用了远程访问 SSL VPN（在 webvpn 配置中有 enable <接口名>），且隧道组中配置了 secondary-authentication-server-group（二次认证）的 ASA / FTD 受影响
• 如果有 tunnel-group-list enable，则包括 DefaultWEBVPNGroup 和登录界面上不显示的配置文件在内的所有隧道组都受影响；没有的话只有 DefaultWEBVPNGroup 受影响
• 与8月的 CVE-2026-20349 不同，IKEv2 客户端服务和 ZTNA 没有被列为受影响的配置
• 不受影响（Cisco 已确认）：Cloud-delivered Firewall、cdFMC、Secure Access、Secure FMC Software。Cisco 运营的云服务无需处理，但自行运维的 ASAv / FTDv 需要升级

处置：各平台和管理方式的修复版本与步骤

• ASA 的修复版：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 系列为 9.24.10.1）
• FTD 的修复版：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
• 没有修复版的系列：ASA 9.19 和 FTD 7.3 已于2026年5月18日结束维护，虽然受影响却没有修复版。ASA 9.19 请迁移到 9.20.4.50 或更高版本，FTD 7.3 请迁移到 7.4.9 或 7.6.7
• 注意不要降级：9.24.10 系列的设备不能改用 9.24.1.27。从编号比修复版还大的热修复版迁移时，也请先用 Software Checker 或 Cisco TAC 确认
• 即将结束维护的系列：ASA 9.16 / 9.18 和 FTD 7.0 / 7.2 将于2026年11月18日停止更新。ASA 建议迁移到 9.20。另外，FTD 兼容性指南中的推荐版本 7.6.6 在本次受影响范围内，Cisco 要求以安全公告中的版本为准
• 获取：下载需要 Cisco.com 账户和维护合同。没有合同的，按照 Cisco 的方针，对于严重漏洞可能个别免费提供，可附上安全公告的 URL 向 TAC 申请
• ASA（单机设备）：先备份配置（Firepower 1000 / 2100、Secure Firewall 1200 / 3100 / 4200 等设备模式的机型，之前指定过非默认 ASDM 镜像的，先执行 configure terminal，再用 asdm image disk0:/asdm.bin 和 write memory 改回来；ASAv、ISA 3000、ASA 5500-X 还要另外复制新的 ASDM 镜像，并在第3步用 asdm image disk0:/<ASDM镜像名> 指定），然后按以下顺序执行

1. 把镜像复制到设备上：copy https://<服务器>/<镜像名> disk0:/<镜像名>（注意，URL 中带密码的话，密码会留在命令行上）
2. 执行 configure terminal 后，用 show running-config boot system 确认当前的启动镜像设置
3. 用 no boot system disk0:/<旧镜像名> 删除旧设置，再用 boot system disk0:/<镜像名> 指定新镜像。ASAv、ISA 3000、ASA 5500-X 最多可以有4条启动设置，要全部删除
4. 用 write memory 保存，用 reload 重启，再用 show version 确认

• 故障切换（Failover）配置：用 failover exec mate copy /noconfirm https://<服务器>/<镜像名> disk0:/<镜像名> 把镜像也复制到备机，修改启动设置后执行 write memory。用 failover reload-standby 重启备机，用 show failover 确认 Standby Ready 后，用 no failover active 切换，再在新的主机上执行一次 failover reload-standby。除 GTP 检测的状态外，可以不停机升级
• 机型限制：Firepower 2100 上的 ASA 以 9.20 系列为最后版本，请升级到 9.20.4.50。Firepower 4110 / 4120 / 4140 / 4150 和 Firepower 9300 的 SM-24 / 36 / 44 以 9.18 系列为最后版本，ASA 5506-X / 5508-X / 5516-X 以 9.16 系列为最后版本，请分别升级到 9.18.4.96 和 9.16.4.104（两者都将于2026年11月18日停止更新）。ASA 5525-X / 5545-X / 5555-X（最高 9.14）以及 ASA 5512-X / 5515-X / 5585-X、ASASM（最高 9.12）没有可运行的修复版。Firepower 4100 / 9300 视需要先升级 FXOS（流量最长会中断约45分钟）。公有云上的 ASAv 也同样用从 Cisco.com 下载的镜像升级
• 由 FMC 管理的 FTD：先升级 FMC。FMC 的版本必须与设备相同或更新（FMC 7.6.7 也已于10月28日发布）。如果 FMC 早于其自身漏洞 CVE-2026-20079（Cisco 评分 CVSS 10.0，9月9日列入 KEV）的修复版（7.4.8、7.6.6 等），请先让管理接口脱离互联网，并优先升级 FMC
• FMC 10.x 在“Administration > Upgrades & updates > Product Upgrades”中升级。HA 对从备机开始升级，主备角色会对调。升级期间不要部署配置，升级后的第一次部署会重启 Snort，检测会短暂中断。第4位补丁版中的修复可能不包含在之后的版本中，升级目标请用 Software Checker 确认
• 由 FDM 管理的 FTD：按 Cisco 的 FDM 升级步骤升级到同样的修复版，再用 show version 确认

暂时无法升级时的缓解措施（临时）

Cisco 表示“没有规避方法”，同时给出了2个临时缓解措施。它们只在 Cisco 的测试环境中验证过，影响需要用户自行判断。

• 情况1（DefaultWEBVPNGroup 未使用二次认证）：执行 configure terminal 后用 webvpn 进入 WebVPN 配置模式，执行 no tunnel-group-list enable。用户将无法在登录界面选择连接配置文件
• 情况2（DefaultWEBVPNGroup 使用了二次认证）：执行 configure terminal 后用 tunnel-group DefaultWEBVPNGroup general-attributes 进入配置模式，再用 no secondary-authentication-server-group 去掉二次认证。少了第二重认证，VPN 的安全性会降低。只做情况1的修改无法脱离受影响范围
• 两种情况修改后都要用 write memory 保存（不保存的话，设备被攻击重启后会恢复原来的配置）
• FTD 需要在 FMC 或 FDM 的远程访问 VPN 策略中做同样的修改并部署，但 Cisco 没有给出针对 FTD 的步骤
• 如果发生了意外重启，可以用 show crashinfo 查看崩溃信息

10月21日面向 FTD 的 Snort 3 相关修复

Cisco 在10月21日的例行发布中，发布了 FTD 的 Snort 3 相关修复。本次的 FTD 修复版（7.6.7 等）都比它们更新。

• Snort 3 加固版本（Cisco 的严重性评级为 Critical）：最高的是 CVE-2026-20043（Cisco 评分 CVSS 9.0）。FTD 的修复版为 7.0.10 / 7.2.12 / 7.4.8 / 7.6.6 / 7.7.13 / 10.0.2 / 10.1.0
• 各个单独公告（MIME、Netflow、GRE、GTP、VBA 宏解压等）均为 Cisco 评分 CVSS 5.3～5.8 的服务中断问题。VBA 宏解压（CVE-2026-20218）只要保持默认的关闭状态就不受影响
• ASA 和 FMC 不在这些公告的受影响产品之列，截至10月31日均未确认被利用。FTD 是否在运行 Snort 3，可以用 show snort3 status 确认

升级后一定要确认的事项

• 确认版本：Ivanti 查看所有节点的“System > Status”，GitLab 用 sudo gitlab-rake gitlab:env:info 和 gitlab-runner --version，ASA 和 FTD 用 show version。Cisco 还要用 Software Checker 确认
• 确认已重启：GitLab 用 sudo gitlab-ctl status 查看运行时间；Ruby 应用要重启常驻进程；容器要重新拉取镜像再重建。ASA 的故障切换配置要用 show failover 确认两台设备
• 升级并不能清除入侵：Ivanti 要做网络和内存取证（内存中的证据会因升级时的重启而丢失，最好在升级前进行），GitLab 要用检测规则检查日志并更换机密信息，Cisco 要确认有无意外重启；如果运行 CVE-2026-20079 受影响版本的 FMC 曾可从互联网访问，还要按 Cisco 的公告检查日志中有无 /var/tmp/license.tmp 的痕迹，发现的话联系 TAC
• KEV 的状态：KEV 随时更新。最新的收录情况和期限可以在 CISA 的 KEV 数据中确认
• 内嵌 GitLab 或 Ruby 的产品，以及使用 Cisco、Ivanti 设备的托管服务，请查看各提供方的信息

官方信息（一手资料）

• Ivanti：Ivanti 安全公告、25.x 兼容性指南、Ivanti 恢复步骤、CISA 警报、Volexity 调查报告、Volexity 的 IOC 和 YARA 规则
• GitLab：19.5.3 发布说明、19.5.1 发布说明、19.4.2 发布说明、升级必经版本、Linux 安装包升级步骤、Runner 升级步骤、Ruby 公告
• Cisco：CVE-2026-76418 安全公告、该公告的日文译文、Snort 3 加固版本、ASA 升级指南
• 公共机构：CISA 列入 KEV 的通告（10月29日）、JPCERT/CC 10月21日周报、JPCERT/CC 10月28日周报

免责声明

本文是 Two Sheep株式会社根据截至2026年10月31日的公开信息整理而成，不对任何产品的运行或安全性作出保证。动手前请务必查看各厂商的最新信息。文中出现的公司名和产品名均为各公司的商标或注册商标。

如果放在数据中心的服务器需要现场处理，例如重启、控制台操作、更换硬件，欢迎咨询我们的远程代维（Remote Hands）服务。