GitLab・Cisco ASA/FTD・Ivanti Connect Secure の2026年10月セキュリティ修正まとめ:影響範囲と環境別の対処手順

2026年10月、Ivanti Connect Secure(CVE-2026-104935 ほか)、GitLab(CVE-2026-97229 ほか)、Cisco ASA/FTD(CVE-2026-76418)で、悪用中の脆弱性を含む修正が相次ぎました。GitLab の CVE-2026-110264(悪用は未確認)も深刻です。影響の確認、修正版と更新手順、暫定策、侵害時の対応をまとめました。
要点
- 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 評価の「悪用あり」は、実際の悪用が確認されていることを示します。
国内では、JPCERT/CC の注意喚起と IPA の緊急情報は、10月31日時点で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(25.1.3.0、25.1.3.1 も、Ivanti は「この脆弱性を含まない」としています)
- 最初の修正版の 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 <名前空間>に出るチャートの版を、GitLab の対応表で読み替えます(例:チャート 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日分のうち CVE-2026-110264 以外の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件を連鎖させた攻撃で、限られた数の顧客が実際に被害を受けたことを確認しています。回避策は公表されていません。
- 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(ビルド 19097)が侵害されました。侵入後には、Active Directory のサービスアカウントを使った 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 は「この脆弱性を含まない」としています。ただし、CVE-2026-111357 / 118527 の修正版として 25.1.3.x を明記しているわけではありません
- 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」です。
- 設定をバックアップします(バイナリ形式の設定バックアップ。Ivanti の KB44759)
- 更新前に ICT を実行して侵害の兆候を確認します(後述)
- 修正版のパッケージを Ivanti License System(ILS)から入手します
- 「Maintenance > System > Upgrade/Downgrade」の「Install Service Package」でインストールします。「Deletes」は選ばないでください。すべての設定が消去されます。インストール後に再起動します
- 「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.1 へは 25.1.3.0 からだけ更新できます
- 25.1.3.0 / 25.1.3.1:Ivanti は「この脆弱性を含まない」としています(前述のとおり、CVE ごとの明記はありません)。最新の 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 の 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 の1アドレスで、遮断の効果は限定的です。主に過去のログの調査に役立ちます
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。侵害された eMudhra の中間 CA 証明書8枚への信頼を取り消す CVE-2026-111943 への対応で、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、push された.gitlab-ci.ymlの処理が入口です。影響版は 19.2.8 / 19.3.5 / 19.4.2 より前の 19.2〜19.4 系です - 深刻度: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日に取り込まれ、公開プロジェクトに push できるアカウントを使う前提です。GitLab の各リリース記事には、10月31日時点で悪用や 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-ruby0.9.12 が、ファイル内のキーワードから正規表現を組み立てる処理で、Onigmo の境界外書き込みを起こします。攻撃用の.orgファイルを置いた公開プロジェクトが1つあれば、認証なしで狙えます。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 のリリース記事には、更新以外の回避策は載っていません。
- 19.3〜19.5 系は、同じ系列の 19.3.7 / 19.4.5 / 19.5.3 へ更新します。19.2 系以前は 19.3.7 以降への移行を計画してください
- 必須の経由版(アップグレードストップ)を飛ばさないでください。GitLab 18 では 18.2・18.5・18.8・18.11、GitLab 19 では 19.2・19.5 が経由版で、19.5.3 へ直接上げられるのは 19.2.x 以降からだけです(Upgrade Path ツール)
- バックアップを取ります。Linux パッケージは更新前にデータベースを自動でバックアップしますが(
/etc/gitlab/skip-auto-backupがあると省略)、GitLab は別途、完全なバックアップを勧めています - 19.5.3 と 19.4.5 にはデータベースのマイグレーションがあり、1台構成では停止時間が発生します
- 今より低い版を指定しないでください。パッケージマネージャーは指定どおりに版を下げます(例: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 チャート:チャートの版は 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 のチャートの手順に従います - Geo(複数サイト):プライマリを先に、続いてセカンダリを更新します。
/etc/gitlab/gitlab-secrets.jsonはすべてのノードで同じでなければなりません。最後にsudo gitlab-rake gitlab:geo:checkで確認します - OS の Ruby を使う GitLab:公式の Linux パッケージとイメージは GitLab が修正した Ruby を同梱していますが、ソースからのインストール、Arch Linux、FreeBSD、NixOS などは OS の Ruby を使います。Ruby も 3.3.13 / 3.4.12 / 4.0.9 以降が必要です。Arch は
sudo pacman -Syuで gitlab19.5.3-1と ruby3.4.12-1がそろいますが、FreeBSD の ports と NixOS unstable の Ruby は10月31日時点で修正前の版です - コミュニティ製の 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ビット):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などが最新です。18.11.8 と 19.1.9 のイメージは10月31日時点で公開されていません
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つの検知ルールを公開しています。例えば CI Lint や GraphQL で Workhorse が 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 です。
- 影響:認証されていない遠隔の攻撃者が、機器を再起動させてサービスを停止させることができます(NULL ポインター参照、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 は日本語の参考訳を公開しています(英語版が優先)。JPCERT/CC の注意喚起と IPA の緊急情報は、10月31日時点で出ていません
影響を受ける構成と製品
- リモートアクセス 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イメージ名>を指定します)、次の順に実行します
- イメージを機器にコピーします:
copy https://<サーバー>/<イメージ名> disk0:/<イメージ名>(URL にパスワードを含めるとコマンドラインに残る点に注意) configure terminalの後、show running-config boot systemで現在の起動イメージの指定を確認しますno boot system disk0:/<古いイメージ名>で古い指定を消し、boot system disk0:/<イメージ名>で新しいイメージを指定します。ASAv、ISA 3000、ASA 5500-X は指定が最大4つまであるため、すべて消しますwrite memoryで保存してreloadで再起動し、show versionで確認します
- フェイルオーバー構成:
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でセカンダリ認証を外します。2つ目の認証がなくなるため、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日号
免責事項
本記事は2026年10月31日時点の公開情報を Two Sheep株式会社が整理したもので、各製品の動作や安全性を保証するものではありません。作業の前に、必ず各提供元の最新情報をご確認ください。記載の社名・製品名は各社の商標または登録商標です。
データセンターに設置したサーバーの再起動、コンソール作業、機器交換など、現地での作業が必要な場合は、当社のリモートハンズサービスにご相談ください。