パッチが出ないKEV脆弱性、Arista EOSが突きつける恒久緩和という選択

2026年6月9日、CISAはArista EOSのトンネル処理の不備であるCVE-2026-7473を、KEV(Known Exploited Vulnerabilities、CISAが実際に悪用が確認された脆弱性を登録するカタログ)に追加した[1][2]。対象はデータセンター向けスイッチで、7020Rシリーズ、7280R/R2シリーズ、7500R/R2シリーズなどArista EOS搭載機器が該当する[1]。CVSSv3.1ベーススコアは5.8(v4.0では6.8)で数値としては中程度だが、実際の悪用が確認されている点が対応の緊急性を押し上げている[2]。この脆弱性でAristaが選んだのは、ソフトウェア修正パッチを恒久的に提供しないという方針である[1][2]。ネットワーク運用チームは、パッチが来ない前提でACLによる恒久緩和策を自ら設計し、運用し続ける決断を迫られている。CISAは連邦文民行政機関に6月23日までの対応を求めており、民間のデータセンター運用にとっても他人事ではない[1][2]。

予備知識

  • ACL(アクセス制御リスト): 通信の送信元・宛先・種別などの条件で許可/遮断を定めるルール群。ネットワーク機器の基本的な防御手段
  • TCAM: ネットワーク機器がACL等の照合を高速に行うための専用メモリ。プロファイル変更は転送に影響しうる
  • デコプセル化: トンネルで包んだパケットから中身を取り出す処理。GREやVXLANはトンネルの代表的なプロトコル
  • KEVカタログ: CISAが「実際に悪用が確認された脆弱性」を登録するリスト。連邦機関には是正期限が課される

同分野を体系的に扱う関連書。

CVE-2026-7473とは何か、何が起きたのか

CVE-2026-7473は、Arista EOSがトンネルのプロトコル種別を検証しない不備に起因する脆弱性である[1][2]。

decap-groups、GREトンネルインターフェース、VXLANなど、デコプセル化用のIPアドレスをトンネル終端として設定した機器では、本来想定していないプロトコルのトンネルパケットでも、宛先IPが一致すれば誤って受理し転送してしまう。攻撃者はこの挙動を利用し、未設定のトンネル経路を通じて内部ネットワークにトラフィックを送り込める余地がある。CISAは2026年6月9日、この脆弱性が実際に悪用されていると判断しKEVカタログに追加した[1][2]。対象製品は7020Rシリーズ、7280R/R2シリーズ、7500R/R2シリーズが中心で、IP-in-IPv6やGUE IPv6のデコプセル化を使う一部構成では7280R3、7500R3、7800R3シリーズにも影響が及ぶ[1]。連邦文民行政機関には6月23日までの是正が義務付けられた[1][2]。

CVE-2026-7473の脆弱性の仕組み
プロトコル種別を検証しないため、宛先IPさえ合えば想定外のトンネルが通る
セキュリティ

すでに廃止されたプロトコルを使い続けることの代償がランサムウェア侵入として現れた。CVE-2026-50751(CVSS 9.3)はCheck Point Remote Access VPN / Mobile Accessが、廃止済みのI[…]

Aristaはなぜパッチを出さないのか

Aristaが恒久パッチを出さない理由は、修正が既存構成を壊すリスクにある。

Aristaは公式アドバイザリで、既存デプロイの設定を壊すリスクがあるためソフトウェアアップグレードによる対応は予定していないと明言した[1]。トンネル終端の検証ロジックを変更すると、正規のGREやVXLAN構成そのものが動作しなくなる可能性がある。パッチ配布による副作用が、脆弱性そのものより広範な障害を招くという判断である。ベンダーが恒久的にコード修正を放棄した事例は珍しく、ネットワーク運用チームは修正待ちという選択肢を最初から失っている。今後は自組織のACL設計とTCAM運用で脆弱性を封じ込め続ける体制が前提になる。

Aristaがパッチを出さない判断の構造
修正の副作用が脆弱性より重いというベンダー判断が、緩和を運用側に委ねた
セキュリティ

Oracleのセキュリティアドバイザリが公開される2週間前から、攻撃者はすでに学校のネットワークを荒らし回っていた。米国のサイバー犯罪グループUNC6240(ShinyHunters)は、Oracle PeopleSoft PeopleT[…]

恒久緩和策の中身とその負荷

Aristaが示す緩和策の柱は二つある。

上流機器でACLを適用し不正なトンネルトラフィックを遮断する方法と、デコプセル化が発生している機器自体にACLを設定する方法である[1][2]。7020R、7280R/R2、7500R/R2シリーズではMAC ACLでの緩和が必要で、User Defined Fields(UDF)を使いパケットヘッダの特定フィールドを照合する設定が求められる。7280R3、7500R3、7800R3シリーズではIP ACLでの対応となる[1]。いずれの場合もTCAMプロファイルの更新を伴い、これはトラフィック転送に影響しうる破壊的操作である[1]。つまり緩和策の適用自体が計画停止やメンテナンスウィンドウを要求する、通常のパッチ適用より重い作業になる。

シリーズ別の恒久緩和策の適用経路
どちらの経路でもTCAM更新を伴い、計画停止枠での適用が前提になる

パッチ適用と恒久緩和、何が違うのか

両者は対応の性質そのものが異なる。

観点パッチ適用恒久緩和(ACL)
対応の性質ベンダーが原因コードを修正運用側がトラフィックを制御し無害化
適用後の再発原則発生しない設定変更・棚卸し漏れで再発しうる
運用負荷アップグレード時のみ恒常的な監視とレビューが必要
今回の可否提供されない[1][2]Aristaが示す唯一の選択肢[1]
副作用リスク構成破壊の可能性をArista自身が指摘[1]TCAM更新に伴う転送影響[1]

対象製品と必要な緩和策も、シリーズごとに異なる。

シリーズ該当構成必要な緩和策
7020R標準構成MAC ACL + UDF
7280R/R2標準構成MAC ACL + UDF
7500R/R2標準構成MAC ACL + UDF
7280R3・7500R3・7800R3IP-in-IPv6・GUE IPv6デコプセル化構成IP ACL
パッチ適用と恒久緩和の性質の違い
パッチは一度で終わるが、恒久緩和は運用に組み込み続ける対応になる

よくある質問(FAQ)

Q1. CVE-2026-7473とは何か、なぜ重大なのか。
A. Arista EOSがトンネルプロトコルの種別を検証しない不備で、想定外のトンネルパケットを誤って受理してしまう脆弱性であり、CISAが実際の悪用を確認しKEVに追加したため重大度が高い[1][2]。

Q2. Aristaはなぜパッチを出さないのか。
A. コード修正が既存のGREやVXLAN構成を壊すリスクがあるためで、Aristaはソフトウェア修正を予定せず、ACLによる恒久緩和を唯一の解として推奨している[1]。

Q3. 対象機種を持つ組織はまず何をすべきか。
A. 対象シリーズの棚卸しを行い、MAC ACLまたはIP ACLとTCAMプロファイル変更を計画停止枠で適用することが必要である。連邦文民行政機関に課された6月23日という対応期限は、民間のデータセンター運用でも参考になる目安になる[1][2]。

まとめ

CVE-2026-7473が示したのは、パッチが必ず来るという前提が崩れる場面が実際に起き得るという事実である。

Aristaは恒久的な修正を放棄し、ACLとTCAM運用による恒久緩和を唯一の解として示した。ネットワーク運用チームは、対象機種の棚卸し、ACL設計、TCAM変更のメンテナンス計画という三点にすぐ着手する必要がある。パッチ前提の脆弱性管理プロセスだけでは、今後同種の事例に対応できない。恒久緩和を平常運用に組み込む設計判断こそ、次のKEV登録に備える現実的な選択になる。

出典

[1] SecurityWeek「No Patch Planned for Exploited Arista EOS Vulnerability」https://www.securityweek.com/no-patch-planned-for-exploited-arista-eos-vulnerability/(WebFetch 403のためWebSearch経由で内容確認、Arista Security Advisory 0137・Rapid7脆弱性データベースの記載と突合)
[2] The Hacker News「CISA Adds Cisco, Chrome, and Arista Flaws to KEV Catalog Amid Active Exploitation」https://thehackernews.com/2026/06/cisa-adds-cisco-chrome-and-arista-flaws.html(WebFetch 403のためWebSearch経由で内容確認、CISA KEVカタログ公式発表と突合)