Cisco Expresswayの脆弱性CVE-2026-76466：クラスタ構成の確認とX15.5.20への更新手順

Ciscoは2026年10月21日、Cisco Expressway-CとExpressway-Eの脆弱性 CVE-2026-76466 を公表しました。クラスタを組んだ機器に、認証なしでネットワーク越しにroot権限のコマンドを実行されるおそれがあり、CVSS v3.1の基本値は9.8です。この記事では、版・クラスタ構成・TLS verification modeによる影響の切り分け、CSAFを使った影響版の照合、修正版X15.5.20へ上げる前に済ませる証明書とEnforce化の準備、更新後の確認、対応の優先度の決め方までを実装と運用の目線で整理しました。内容は2026年10月24日時点の公開情報にもとづきます。

まとめ：クラスタ構成のExpresswayはX15.5.20へ更新し4371番を絞る

CVE-2026-76466の対象は、X15.5.3以前の版で動き、クラスタを構成している物理版・仮想版のExpressway-CとExpressway-Eです。回避策は無く、X15系はX15.5.20へ、X14以前は修正のある版への移行で塞ぎます。悪用はまだ確認されていません。

X15.5.20には、更新前にクラスタの証明書とTLS verification modeを点検する仕組みが入っており、要件を満たさないノードは再起動の前に止まります。先に証明書のSANと署名方式を直し、TLS verification modeをEnforceへ切り替えてから更新に入るのが、作業を止めない順番です。

更新までの間は、クラスタ通信のTCP 4371番をピアのアドレスだけに絞ります。ただしCiscoはこれを多層防御と位置づけており、更新の代わりにはなりません。社外に面したExpressway-Eを含むクラスタから先に着手してください。入口機器の版と露出をまとめて棚卸ししたい場合は、脆弱性診断・セキュリティ診断で点検範囲を決めると抜けが出にくくなります。

CVE-2026-76466の中身：クラスタDBの永続Cookieとroot実行の仕組み

Expresswayは、社外のスマートフォンやPCをCisco Unified CMへつなぐモバイル・リモートアクセス（MRA）や、企業間のビデオ通話を中継する機器です。社内側にExpressway-C、DMZ側にExpressway-Eを置く構成が一般的で、冗長化と処理能力のために同種の機器でクラスタを組みます。今回の欠陥は、そのクラスタの中で動くデータベースサービスにありました。

CWE-798とCVSS 9.8の内訳と悪用未確認・KEV未登録という現在地

Ciscoのアドバイザリ cisco-sa-vcs-static-cred-hr7EWZ8tによれば、原因は永続的なCookieの使用です。加えて、クラスタのTLS Verify Modeが有効な場合にもクライアント証明書の検証が不十分でした。Cookieを手に入れた攻撃者は、データベースサービスへ接続して特定のRPCコマンドを呼び出すことで、基盤OS上でrootとしてコマンドを実行できます。弱点の分類はCWE-798（ハードコードされた認証情報の使用）です。

どのCookieかはアドバイザリに書かれていません。手がかりになるのはX15.5.20のアップグレードチェックリスト（TAC文書226432）で、更新時にクラスタCookieの再暗号化でクラスタ通信のアラームが一時的に出ること、TACへ渡す資料からクラスタCookieを伏せることが書かれています。クラスタ内の通信を認める値が長期間そのまま使われていた、と読むのが自然です。ここは公開情報からの推定です。

CVSSのベクトルは AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H で、各指標の読み方はCVSSv3の計算式とスコアの目安で確認できます。Cisco PSIRTは公表時点で悪用や攻撃コードの公開を把握していません。CISAのKEVカタログも、2026年10月23日版には載っていませんでした。発見者はJane StreetのStefan Aleksic氏です。

同日公開の強化リリースに含まれる8件のCVEとの関係と修正版X15.5.20

同じ日に、Expresswayのセキュリティ強化リリースのアドバイザリも出ています。Ciscoの社内検査で見つかった脆弱性を弱点の型ごとに8つのCVEへまとめたもので、修正版はCVE-2026-76466と同じX15.5.20です。

強化リリース側は機器の構成に関係なく対象になります。このため、クラスタを組んでいない単独のExpresswayも、時期は別にしてX15.5.20へ上げる対象です。強化リリースのCVSS 8.6はベクトルの影響が可用性（A:H）だけで、サービス停止型の欠陥が中心だと読めます。

影響範囲の切り分け：版・クラスタ構成・TLS verification modeの3条件

CVE-2026-76466に当たるかどうかは、版がX15.5.3以前か、クラスタを組んでいるかで決まります。TLS verification modeの値は、影響の有無ではなく更新作業の準備に関わる項目です。

xstatusとCSAFのJSONで92の影響版と自社の版を照合する手順

版はCLIで確認できます。TAC文書118675にある手順のとおり、SSHでadminとしてログインし、状態と設定を出力します。

# SSHでadminとしてログインしてから実行する
xstatus
xconfig

xstatusの出力ではSystemUnit配下のSoftwareにあるVersionが版です。xconfigの出力ではClusterの項目にTlsVerifyとピアのアドレスが並びます。X8.2以降なら、Web管理画面の「Maintenance > Diagnostics > Diagnostic logging」で採る診断ログにも、同じ内容がxstat_dump.txtとxconf_dump.txtとして入ります。

機器が多い場合は、Ciscoが公開している機械可読のアドバイザリ（CSAF形式のJSON）を読み、資産台帳の版と突き合わせると漏れを防げます。次のPythonは標準ライブラリだけで動きます。

import json
import sys
import urllib.request

CSAF_URL = ("https://sec.cloudapps.cisco.com/security/center/content/"
            "CiscoSecurityAdvisory/cisco-sa-vcs-static-cred-hr7EWZ8t/csaf/"
            "cisco-sa-vcs-static-cred-hr7EWZ8t.json")


def product_names(node, names):
    # product_tree を再帰的にたどり、版名（X〜）の product_id と版名の対応表を作る
    for branch in node.get("branches", []):
        product = branch.get("product")
        if product and branch["name"].startswith("X"):
            names[product["product_id"]] = branch["name"]
        product_names(branch, names)
    return names


req = urllib.request.Request(CSAF_URL, headers={"User-Agent": "Mozilla/5.0"})
csaf = json.load(urllib.request.urlopen(req, timeout=30))
names = product_names(csaf["product_tree"], {})
status = csaf["vulnerabilities"][0]["product_status"]
affected = {names[pid] for pid in status["known_affected"] if pid in names}

print("影響版の数:", len(affected))
for version in sys.argv[1:]:
    hit = "影響版一覧に該当" if version in affected else "一覧に無し"
    print(version, hit)

python csaf_check.py X8.11.4 X14.3.7 X15.5.3 X15.5.20 のように版を並べて実行します。2026年10月24日の取得では、影響版としてX8.1からX15.5.3までの92版が並び、X8.11.4・X14.3.7・X15.5.3は該当、X15.5.20は一覧にありませんでした。CSAFの葉の分類は版ではなく「service_pack」になっているため、分類名ではなく版名の先頭の「X」で拾っています。

Clustering画面でピア数とTLS検証モードを確かめる見方と単独機の扱い

クラスタを組んでいるかは、Web管理画面の「System > Clustering」で分かります。TAC文書217230によれば、この画面にはConfiguration primary、TLS verification mode、Peer 1 addressから始まるピアのアドレス欄があります。ピアのアドレスが2つ以上入っていればクラスタ構成で、CVE-2026-76466の対象です。

TLS verification modeはPermissive（既定）とEnforceの2択です。Permissiveではピア同士が相手の証明書を検証しません。既定のまま運用している環境は多いはずで、後述の更新準備でここが最初の作業になります。

ピアのアドレス欄が空の単独機は、CVE-2026-76466の条件から外れます。一方で強化リリースの対象には入るため、計画的な更新の対象として台帳に残してください。なお、ピアのアドレスをすべて空にして保存し再起動すると、設定がほぼ消える工場出荷状態に戻ると217230は注意しています。確認のつもりで欄を消さないでください。

X15.5.20へのアップグレード前に済ませる証明書とEnforce化の準備

X15.5.20は、クラスタの更新を始める前に全ピアの準備状態を検査します。検査に通らないノードは再起動の前に止まり、既存のクラスタ構成は変わりません。止まること自体は安全側の動きですが、保守時間内に終わらなくなるので、検査項目は事前に潰しておきます。

opensslでピア証明書のSAN・鍵長・署名方式を事前に点検するコマンド

チェックリスト226432が挙げるクラスタの証明書要件は次のとおりです。

• SANにシステムのFQDNが入っている（SANがある場合はCNを見ない）
• 有効期間内で、全ピアが発行元を信頼している
• 鍵がRSA 2048ビット以上か、P-256以上の楕円曲線
• 署名がSHA-2系（SHA-1はX15.2からサポート外）

チェックリストはTACへ渡す証拠としてopenssl x509 -text -nooutの出力を挙げています。各ピアのサーバ証明書（PEM）を書き出し、同じコマンドの出力から要件に関わる行だけを抜き出すと、点検が早く済みます。

# ピアごとのサーバ証明書を点検する（秘密鍵は扱わない）
openssl x509 -in expc1.pem -text -noout \
  | grep -E -A1 "Subject Alternative Name|Not After|Public-Key|Signature Algorithm"

SANの行にシステムのFQDNが無い、Public-Keyが2048 bit未満、Signature Algorithmがsha1WithRSAEncryptionのいずれかなら、更新前に証明書を発行し直します。発行し直しの際は、MRAで使うDNS名も含めて必要な名前をすべてSANに入れます。

PermissiveからEnforceへの切り替えとFQDN統一で止まらない順序

チェックリストは、保守時間の前にTLS verification modeをEnforceへ切り替え、構成プライマリから順にクラスタを再起動するよう求めています。X15.5.20ではPermissiveはサポート外です。Enforceでは、ピアのアドレスに証明書のCNかSANと一致するFQDNを入れる必要があります。

1. 全ピアの証明書を前述の要件に合わせ、発行元を全ピアで信頼させる。
2. ピアのアドレスをすべてFQDNにそろえる（IPアドレスとの混在は更新前の検査で止まる）。
3. TLS verification modeをEnforceにし、構成プライマリから順に再起動する。
4. Clustering画面で全ピアのClusteringとCertificateの状態が正常、Cluster database statusがActiveになるのを待つ。
5. 全ノードのバックアップを取ってから、更新に入る。

相互に証明書を確かめ合う仕組みそのものはmTLSの仕組みとクライアント証明書の運用で解説しています。手順2のアドレス形式は、ローリングアップグレードの途中で変えてはいけません。途中で変えると、更新済みと未更新のノードで相手の識別が食い違います。

X8.11.4より前・X14以前・PAKライセンスが残る機器の移行経路

古い版からは一気にX15.5.20へ上げられない場合があります。チェックリストは、X8.11.4より前の版はいったんX8.11.4で止めること、X12のPAKライセンスはX15系へ上げる前にSmart Licensingへ切り替えることを求めています。PAKのオプションキーはX14.2で廃止済みで、X15.5.20ではSmart Licensingだけが使える仕様です。

X14以前の機器はアドバイザリ上「修正版へ移行」の扱いで、X14系の修正版は出ていません。ハードウェアの世代によってはX15系の要件を満たさないこともあるため、仮想版への載せ替えを含めて移行計画を立てることになります。

アップグレード後の確認：4371番の相互TLSと管理者ログインの変化

X15.5.20は脆弱性の修正に加えて、管理者認証やAPIの扱いも厳しくしています。通話が通ることだけを見て完了にすると、翌日の運用で詰まります。

ノードの版・クラスタDB・TlsVerifyの確認と一時的なアラームの扱い

チェックリストが更新後の確認として挙げるのは、全ノードの版がX15.5.20であること、全ピアがクラスタに参加しレプリケーションが正常なこと、TlsVerifyがEnforceのままであることです。クラスタ通信はTCP 4371と4372の相互TLSになり、有効なクライアント証明書を持たない接続は失敗します。

更新直後にクラスタ通信のアラームが出ることがあります。クラスタDBの再暗号化によるもので、イベントログにdeveloper.upgradeのメッセージと「Saving migrated data to CDB.」が出たあと自然に解消する想定です。消えない場合は各ピアの状態とスナップショットを集めてTACへ渡します。このとき、クラスタCookieや鍵の情報はケースのメモに書きません。工場出荷状態へ戻して回避するのも禁物で、クラスタの識別情報とクラスタCookieが消えてしまいます。

パスワード履歴12件・UTC基準の期限・LDAP完全一致で詰まる箇所

管理者まわりでは、次の変更が入ります。運用手順書や監視の設定に影響するものを先に挙げます。

LDAPのグループ名を部分一致で割り当てていた環境では、管理者が権限を失ってログインできなくなります。設定を自動化しているスクリプトは、名前とパスワードの検証の厳格化と、削除された/provisioning/optionkeyの呼び出しに注意が要ります。STARTTLSを完了できない宛先へのアラートメールは平文に戻らず送信に失敗するため、テストメールを1通送って確かめてください。

Expressway-Eを含むクラスタから即日対応するかを決める優先度の判断

悪用が未確認で、KEVにも載っていない段階です。それでも全台を同じ速さで扱う必要はありません。露出で順番を決めます。

4371番が外部から届く構成を最優先にし単独機は計画更新に回す基準

最優先は、Expressway-Eを含むクラスタで、TCP 4371がピア以外から届く構成です。ファイアウォールのルールを確かめ、DMZの別セグメントや社外から到達できるなら今週中に更新します。Expressway-Eは社外からの通話を受けるため、もともと社外に面した構成です。そのクラスタ通信の口が開いていれば、攻撃者の位置に関わらず条件がそろいます。

次が、4371番をピアだけに絞れているクラスタです。Cookieを手に入れる段階が必要な分、攻撃の手順は1つ増えます。とはいえroot実行に至る欠陥で回避策も無いため、次の定期保守を待たず、証明書の準備が整いしだい更新します。

単独機は、CVE-2026-76466の条件に当たりません。強化リリースのCVEは構成を問わず当たりますが、Ciscoが示す影響はサービス停止が中心で、悪用も未確認です。月次の計画更新に組み込めば足ります。単独機まで夜間の緊急作業で上げるのは、作業の負荷に見合いません。

ポート制限を回避策と見なさない理由と更新までに打てる暫定運用の範囲

4371番をピアだけに絞るのは、チェックリストが更新後にも求める設定です。更新までの間にも有効ですが、Ciscoはこれを多層防御と位置づけ、更新の代わりにならないと明記しています。アドバイザリの回避策も「なし」です。ピアのいずれかが侵害されれば、その機器は許可された接続元になるからです。

暫定運用として打てるのは、4371・4372番の接続元をピアに限ること、管理画面とSSHへの接続元を管理用の端末に限ること、クラスタのピア以外からの接続をファイアウォールのログで見張ることの3つです。逆に、TLS verification modeをEnforceにするだけで安心するのは誤りです。アドバイザリは、TLS Verify Modeが有効な場合にもクライアント証明書の検証が不十分だったと書いています。同じ月にはCisco製品の入口機器で、悪用済みのSecure Email Gatewayの脆弱性CVE-2026-76519も出ました。Cisco製品が複数ある組織は、案件をまたいで版と露出を点検する進め方を脆弱性診断の進め方と外注時の判断基準で確認しておくと、次の公表時に初動が早くなります。

Cisco ExpresswayのCVE-2026-76466対応でよく受ける質問と回答

CVE-2026-76466の対応を進める際に出てきやすい疑問に、公開されている一次情報の範囲で答えます。

クラスタを組んでいない単独のExpresswayも更新は必要ですか？

必要です。ただし急ぐ度合いが違います。CVE-2026-76466はクラスタ構成が条件なので単独機は外れますが、同日の強化リリースに含まれる8件のCVEは構成に関係なく当たり、修正版は同じX15.5.20です。悪用は未確認で影響はサービス停止が中心のため、月次の計画更新に入れて、更新前のバックアップと証明書の点検を済ませてから進めれば十分です。

TLS verification modeのEnforce化は回避策になりますか？

なりません。アドバイザリは、TLS Verify Modeが有効な場合にもクライアント証明書の検証が不十分だったことを原因の1つに挙げており、回避策は無いとしています。Enforce化は、X15.5.20へ上げるための前提条件です。更新の準備として先に済ませ、そのうえで版を上げる、という順番で考えてください。

X15.5.3より後でX15.5.20より前の版を使っている場合は？

アドバイザリの修正版の表は「X15.5.3以前はX15.5.20で修正」とだけ書いており、その間の版には触れていません。CSAFの影響版一覧もX15.5.3が最後です。その間の版を使っている場合は、CSAFの照合結果だけで安全と判断せず、X15.5.20への更新を前提に、Cisco TACか保守契約先へ扱いを確認してください。

Expressway以外のCisco製品やVCSの旧機は対象になりますか？

アドバイザリが影響製品として挙げているのは、Expressway-CとExpressway-E（物理版・仮想版）だけです。影響しないことを確認した製品の一覧は示されていません。CSAFの製品名にはVCS Expresswayの旧称が残っており、同系統のソフトウェアをVCSとして運用している環境は、版がX8.1〜X15.5.3の範囲に入るかを確かめ、サポート状況とあわせて保守契約先へ確認するのが確実です。

JPCERT/CCの注意喚起やCISAのKEV登録は出ていますか？

2026年10月24日時点で、JPCERT/CCの2026年の注意喚起一覧に本件はありません。CISAのKEVカタログ（2026年10月23日版）にも載っていません。悪用が確認されればKEVに載り、米国の連邦機関には短い対応期限が課される仕組みです。期限の決まり方はBOD 26-04の是正期限の決まり方で解説しています。載ってから準備を始めると、証明書の発行し直しで数日を失います。

関連記事

• 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説：脆弱性が公表から修正に至る流れの基礎を確認できます。
• CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化：CVE-2026-76466のような識別子とCWE・CSAFの関係を整理しています。
• VPN 脆弱性：機器の版確認コマンドとKEV照合スクリプト・パッチと移行の判断【2026年10月】：社外に面した入口機器の版をKEVと照合する考え方をVPN機器で解説しています。
• Snort 3の脆弱性CVE-2026-76524と3.12.4.0：版確認・制御ソケット点検・更新手順：同じ10月に公表されたCisco系ソフトウェアの脆弱性対応です。
• CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説：単発の緊急対応から、露出を継続的に管理する運用へ移す考え方です。