結論：「パッチを待つ」という選択肢が存在しない。緩和・分離・更改の3択を今すぐ決める
Aristaのネットワーク機器OS「EOS」のトンネル処理に関する脆弱性 CVE-2026-7473 は、すでに 実際の悪用が報告されている にもかかわらず、Aristaは 「既存環境の構成を壊すリスクがあるため、本問題に対処するソフトウェアアップグレードの提供は計画していない」 と明言した。米CISAは6月9日、本脆弱性を悪用が確認された脆弱性カタログ（KEV）に追加している。
つまり対象機器を使う企業にとって、「修正版が出たら当てる」という通常のパッチ運用が最初から成立しない。取り得る手段は、ベンダーが示すACL（アクセス制御リスト）による緩和策の適用、対象機能・対象機器の分離、あるいは機器更改の3つだけだ。
さらに同日のKEV追加はArista単独ではない。Cisco Catalyst SD-WAN ManagerのCVE-2026-20245、ChromeのCVE-2026-11645も同時に登録 されており、ネットワークの中核を担う機器・管理基盤への悪用が同じ週に並んだ。境界やWAN基盤を「導入したベンダー任せ」にしている企業ほど、この種の通知に気づかないまま放置するリスクが高い。
押さえるべき1点：「悪用済みなのにパッチが出ない」脆弱性では、対応の主導権が完全に利用者側へ移る。緩和策の設計・適用は自社（または保守ベンダー）の仕事であり、待っていても安全にはならない。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
CVE-2026-7473の概要と影響範囲
Aristaのセキュリティアドバイザリ（Security Advisory 0137）によれば、概要は次のとおりだ。
| 項目 | 内容 |
|---|---|
| 脆弱性 | トンネルプロトコル種別の検証不備。VXLAN・GREなどのトンネル終端（デカプセル化）を構成した機器が、設定していない種類のトンネルパケットまで誤って復元・転送し得る |
| CVSS | Arista公表値はCVSSv3.1で5.8、CVSSv4.0で6.8 |
| 影響プラットフォーム | 7020Rシリーズ、7280R/R2シリーズ、7500R/R2シリーズ。7280R3・7500R3・7800R3シリーズは特定条件（IP-in-IPv6、GUE IPv6など）で限定的に影響 |
| 影響バージョン | EOS 4.30.x〜4.36.x系列を含む広範なリリースが対象 |
| 悪用 | 「実際に悪用されている（exploited in the wild）」とアドバイザリに明記。CISAは6月9日にKEV登録、米連邦機関の対処期限は6月23日と報じられている |
| 修正 | 提供予定なし（既存構成を破壊するリスクを理由にアップグレードでの対処を計画しないと明言） |
| 緩和策 | ①上流機器でのACLにより正規のトンネルトラフィックのみを選択的に許可 ②デカプセル化を行う機器側でUDF（User Defined Fields）を用いたMAC ACLを適用（TCAMプロファイルの更新が必要） |
注目すべきは、CVSSスコアが「中程度」でもKEVに登録された 点だ。KEVはスコアの高低ではなく「実際に悪用されているか」で選定される。深刻度の数字だけで対応優先度を決めている組織は、本件のような「点数は低いが現に攻撃されている穴」を取りこぼす。悪用実態を優先する考え方は、フィッシングを抜いて脆弱性悪用が侵入経路の主流になったという調査（Cisco Talos分析の解説）とも整合する。
同時にKEV登録されたCisco Catalyst SD-WAN Manager
同日KEVに追加された CVE-2026-20245 は、Cisco Catalyst SD-WAN Manager（旧vManage）の脆弱性で、CVSSスコア7.8。認証済みのローカル攻撃者が細工したファイルを与えることでroot権限の任意コマンド実行に至り得ると報じられている。SD-WANの管理基盤は全拠点のネットワーク設定を握る「鍵束」であり、侵害されれば影響は1台の機器に留まらない。Catalyst SD-WAN利用企業は修正適用とあわせて、管理画面へのアクセス経路（誰が・どこから・どの権限で）を点検すべきだ。なお同時登録のChromeゼロデイはChrome今年5件目のゼロデイCVE-2026-11645の解説で扱っている。
なぜ「直さない」のか——パッチ前提のセキュリティ運用が崩れる日
Aristaが修正を見送った理由は「修正によって既存デプロイの構成が壊れるリスク」だ。トンネル処理の挙動を厳格化すると、これまで動いていた正規構成まで止まりかねない。利用者全体への影響と脆弱性のリスクを天秤にかけ、ベンダーは「直さずに緩和策を案内する」側に倒した ことになる。
これは例外的な事件ではなく、今後増える構造的な現象と捉えるべきだ。製品が成熟しレガシー化するほど、修正の副作用は大きくなり、ベンダーがパッチを出さない・出せないケースは増える。サポート終了（EOS/EOL）製品に修正が出ないのは従来からの常識だが、本件は 現役製品ですら「悪用済み・修正なし」があり得る ことを示した。
そのとき自社を守るのは、次の3択を判断できる体制だ。
-
緩和（Mitigate）：ベンダー提供の回避策（本件ならACL）を自社構成に合わせて設計・適用する
-
分離（Isolate）：該当機能の無効化や、対象機器が処理するトラフィック・セグメントの限定で露出を減らす
-
更改（Replace）：緩和も分離も成立しない場合、機器・構成そのものの更改を期限付きで計画する
いずれも「ネットワーク構成を自社として把握していること」が前提になる。VPN機器の悪用事案（Check Point VPN認証バイパスの解説）でも同じ教訓が出たばかりだ。構成を把握していない企業は、対象かどうかの判定すらできない。
確認手順：対象判定から緩和策適用まで
-
資産台帳・構成管理でArista機器の有無を確認する。自社購入だけでなく、SIer・データセンター事業者経由で納品された機器も含める
-
該当プラットフォーム（7020R/7280R・R2/7500R・R2系列等）かどうかを照合する。不明なら保守ベンダーに書面で確認する
-
トンネル終端構成（VXLAN・GRE等のデカプセル化）の有無を確認する。構成がなければ本件の影響は受けないが、台帳の整備は続ける
-
該当する場合、アドバイザリの緩和策（上流ACLまたはUDFを用いたMAC ACL）を自社構成に合わせて設計・適用する。TCAMプロファイル更新を伴うため、検証手順と切り戻し計画を用意する
-
Cisco Catalyst SD-WAN Managerの利用有無を確認し、利用中なら修正適用と管理画面のアクセス制御を点検する
-
KEV登録情報をパッチ運用の入力に組み込む。CVSSスコア順ではなく「悪用確認済みを最優先」に並べ替える
チェックの勘所：本件の対応完了条件は「パッチ適用済み」ではなく「緩和策の適用と検証が済んでいる」こと。保守ベンダーから「修正パッチの提供はない」という回答が返ってきたら、それは対応不要の意味ではなく、緩和策設計の依頼を出すべき合図である。
よくある質問（FAQ）
Q. CVSSスコアが5.8〜6.8と「中程度」なのに、なぜ急いで対応する必要があるのか？ A. CVSSは攻撃の成立条件や技術的影響を機械的に評価した数字であり、実際に攻撃されているかどうかは反映されない。本件は悪用が確認されKEVに登録された——つまり攻撃者が現に使っている穴だ。スコアの高低より悪用実態を優先するのが、現在の脆弱性管理の定石である。
Q. ベンダーがパッチを出さない場合、利用者は何をすればよいのか？ A. 選択肢は緩和・分離・更改の3つに集約される。まずベンダー公式の緩和策（本件はACL）を適用し、それが自社構成で成立しない場合は対象機能の無効化やセグメント分離で露出を下げる。どちらも難しければ、機器更改を「いつか」ではなく期限付きの計画にする。放置だけが選択肢にない。
Q. 自社のネットワークにArista機器があるかどうか分からない。何から始めるべきか？ A. データセンターや拠点間ネットワークの構築を委託したSIer・保守ベンダーに「Arista機器の有無」「該当プラットフォーム・トンネル構成の有無」「緩和策適用の予定日」を書面で確認すること。回答を検証できる体制が社内にない場合は、第三者によるネットワーク構成の棚卸し・診断を併用するのが現実的だ。
社内で今日確認する実務チェック
この記事のテーマを自社に当てはめるときは、次の順で確認する。第一に、対象製品・対象バージョン・対象サービスが資産台帳に載っているか。第二に、インターネットや不要な社内セグメントから到達できないか。第三に、更新・緩和・監視の担当者と期限が明確か。第四に、委託先やクラウド運用先が関係する場合、回答を口頭ではなくチケットやメールで記録しているか。第五に、対応後にバージョン・設定・ログで完了を確認したかである。
脆弱性対応で最も危険なのは、「使っているか分からない」「担当が分からない」「ベンダーに任せているはず」という状態だ。今回の記事を読んだ時点で対象有無を即答できないなら、それ自体が改善テーマである。個別のパッチ適用だけでなく、資産台帳、脆弱性通知の受信経路、緊急対応の承認権限まで点検したい。
GXOへ相談する前に整理しておくと早い情報
相談前には、対象製品名、バージョン、設置場所、外部公開の有無、管理者、保守契約、更新可能な時間帯、過去の障害履歴を分かる範囲でまとめる。すべて揃っていなくてもよいが、「分からない項目」が多いほど、最初の支援はパッチ作業ではなく棚卸しと露出確認から始めるべきである。
30日で整える脆弱性対応ロードマップ
初日から3日目までは、対象有無の確認と暫定緩和に集中する。資産台帳、EDR/MDM、クラウド管理画面、保守ベンダーへの照会を使って、対象製品がどこにあるかを洗い出す。対象が見つかった場合は、外部公開の停止、アクセス制限、管理画面のIP制限、監視強化など、更新前にできる緩和策を先に入れる。
4日目から10日目までは、更新・設定変更・影響確認を進める。業務影響が大きい製品では、検証環境で更新手順を確認し、失敗時の切り戻し手順を用意する。更新後はバージョン表示だけでなく、実際に脆弱な経路が閉じているか、ログに不審なアクセスが残っていないかを確認する。
11日目から30日目までは、再発防止に使う。通知を誰が受けるか、KEVやJPCERT/CCなどの情報をどう優先度付けするか、休日・夜間の緊急判断を誰が承認するかを決める。今回のような高リスク通知に対して、次回は「対象有無を24時間以内に答えられる」状態を目標にする。
いつGXOに相談すべきか
-
ネットワーク機器の構成・バージョンを自社で把握できておらず、対象判定から支援が必要
-
保守ベンダーから「パッチなし」と回答されたが、ACL緩和策を設計・検証する技術力が社内にない
-
パッチが出ない・サポートが切れる機器が増え、ネットワーク全体の更改計画を作りたい
GXOは、セキュリティ診断によるネットワーク構成・境界機器の棚卸しと露出評価、脆弱性診断による対象判定、セキュリティ顧問によるKEVベースのパッチ・緩和策運用の伴走を提供している。「直してもらえない脆弱性」は今後も増える。自社で判断できる体制づくりを急ぎたい段階での相談に対応する。→ 相談はこちら
関連記事
参考資料
-
CISA「CISA Adds Three Known Exploited Vulnerabilities to Catalog（2026年6月9日）」
-
SecurityWeek「No Patch Planned for Exploited Arista EOS Vulnerability」（二次情報）
本記事は2026年6月12日時点の公開情報をもとに作成。米連邦機関の対処期限（6月23日）およびCisco CVE-2026-20245の詳細は報道時点の情報である。影響範囲・緩和策の詳細は更新される可能性があるため、AristaおよびCISAの一次情報の最新版を必ず確認すること。
「パッチはありません」と言われたネットワーク機器、放置していませんか
ネットワーク構成の棚卸しと対象判定、ACL緩和策の設計・検証、更改計画の立案まで一気通貫で支援します。悪用済み・修正なしの脆弱性は待っていても安全になりません。判定段階からの相談に対応します。
※ 営業電話はしません | オンライン対応可 | 緊急時は最短当日対応