「最新のパッチさえ当てていれば安全」という前提を、根本から揺さぶる出来事が2026年8月26日に起きた。米CISA（サイバーセキュリティ・インフラセキュリティ庁）が実際に悪用が確認された脆弱性を集めるKEV（Known Exploited Vulnerabilities）カタログに、発行から最短でも4年、最長で11年が経過した古いCVE（共通脆弱性識別子）を一括で追加したのだ。何年も同じシステムを稼働させ続けている企業のIT基盤担当者にとって、これは「枯れたシステムだから大丈夫」という判断がいつ崩れてもおかしくないという警告になる。
予備知識
- KEV（Known Exploited Vulnerabilities）カタログ: CISAが運営する、実際に悪用が確認された脆弱性の一覧。米連邦機関は、インターネットに露出した資産を優先して対応し、リスクの低いものは後回しにすることが求められる。
- CVE: 個々の脆弱性に付与される共通識別子。「CVE-発行年-通し番号」の形式で、発行年が古いからといって危険度が下がるとは限らない。
- BOD（Binding Operational Directive）: CISAが米連邦機関に発する拘束力のある運用指令。KEV掲載脆弱性の対応期限などを定める。
- シンボリックリンク攻撃: 本来アクセスすべきファイルの代わりに、攻撃者が用意した別ファイルへのリンクを踏ませることで、権限のあるプロセスに意図しない操作をさせる手口。
KEVとの突合を続けるには、そもそも何が稼働しているかを継続的に把握する仕組みが要る。資産管理の標準的な枠組みを押さえたい担当者向け。
何が追加されたのか：4年から11年前のCVEが一堂に
CISAが2026年8月26日に追加した6件のうち、5件は「今年新規発行されたCVEではない」という共通点を持つ[1]。内訳は次の通りだ。
| CVE | 対象 | 発行年 | 経過年数 | 脆弱性の性質 |
|---|---|---|---|---|
| CVE-2015-3246 | Red Hat libuser | 2015年 | 約11年 | 競合状態による/etc/passwd破損（権限昇格・DoS） |
| CVE-2015-5287 | Red Hat ABRT | 2015年 | 約11年 | シンボリックリンク攻撃による権限昇格 |
| CVE-2019-1068 | Microsoft SQL Server | 2019年 | 約7年 | リモートコード実行 |
| CVE-2021-23758 | Ajax.NET Professional | 2021年 | 約5年 | 逆シリアル化による任意.NETクラス実行 |
| CVE-2022-0995 | Linuxカーネル | 2022年 | 約4年 | 境界外書き込みによる権限昇格・DoS |
いずれも公開当初は「発見された脆弱性」として粛々とパッチが提供されただけで、大きな話題にはならなかった。ところが2026年になって、脅威インテリジェンスの分析から「これらが今なお実際の攻撃で使われ続けている」ことが判明し、まとめてKEV入りした[2][3]。KEVカタログの対応期限は2段階に分かれている。CVE-2019-1068とCitrix NetScalerのCVE-2026-8452が2026年8月29日、残る4件が9月9日だ[2][3]。
資産棚卸しの優先順位をリスクベースで決める考え方を、監査実務の視点から学べる一冊。
なぜ「古いCVE」が今さら問題になるのか
KEVは新規発見された脆弱性のためだけのカタログではない。CISAは公開時点で悪用の証拠がなくても、後になってCisco Talosが公表した攻撃キャンペーン（UAT-10147）の解析から「この脆弱性が使われていた」と判明すれば、発行年に関わらず追加する運用をとっている。今回のケースが物語るのは、パッチが存在する脆弱性であっても、何年も前のバージョンのまま放置されたシステムが世界中に相当数残っているという実態だ。
Red Hat libuserやABRTはLinuxディストリビューションの基盤ツールであり、SQL Serverは業務データベースの定番、Ajax.NET Professionalは.NET系Webアプリケーションで広く使われてきたライブラリだ。いずれも「入れ替えるには影響範囲が大きい」種類のコンポーネントであり、これが長期間パッチ未適用のまま残存しやすい理由でもある。
SD-WAN管理基盤である VeloCloud Orchestrator（VCO、複数拠点のSD-WAN機器を一元管理するオンプレ型オーケストレータ）に、CVSS基本値が最大の10.0となる脆弱性が見つかった。認証情報を一切必要とせず、W[…]
資産棚卸しの「見えている範囲」を疑う
多くの企業の脆弱性管理は、直近1〜2年に発行されたCVEを優先的に追いかける運用になりがちだ。理由は単純で、新しいCVEほど攻撃者の関心が高く、優先度スコアも高く出るためだ。しかし今回のように、10年以上前のCVEが後から実悪用の証拠とともにKEV入りするケースがある以上、「古いCVEは対応済みのはず」という前提そのものを定期的に検証し直す必要がある。
具体的には、脆弱性スキャンの対象を直近発行分だけに絞らず、稼働中の全資産に対して発行年を問わずKEVカタログとの突合を定期実行する運用が求められる。特にRed Hat系ディストリビューションのユーティリティ群や、業務システムに組み込まれたまま更新されていないライブラリは、担当者の意識から外れやすい領域だ。
ingress-nginxは、Kubernetesクラスタの外部からのHTTP/HTTPS通信を制御するIngressコントローラとして、長く事実上の標準だった。この開発が2026年3月24日、GitHubリポジトリのアーカイブという形で[…]
日本企業の「長く動かす文化」は棚卸しの死角と両立できるか
日本企業のシステムは、海外に比べて長期間同じバージョンを稼働させ続ける傾向が強い。基幹システムや業務アプリケーションを10年以上更新せずに使い続けることは珍しくなく、その裏側にRed Hat系OSやSQL Server、.NET系ライブラリが何年も前のバージョンのまま存在していても不思議ではない。今回のKEV追加が示すのは、この「長く動かす」文化そのものが悪いのではなく、動かし続けているシステムの中身を定期的に棚卸しし直す仕組みが伴っていないと危険が積み上がるということだ。
| 観点 | 海外企業で進みやすいこと | 日本企業で起きやすいこと |
|---|---|---|
| 棚卸しの頻度 | 資産管理ツールで継続的に自動突合 | 監査前にまとめて手動棚卸し |
| 古いシステムの扱い | 更新かリプレースかを定期的に議論 | 「動いているから触らない」判断が続く |
| 委託先との役割分担 | 脆弱性管理をSLAで明文化 | 保守契約の範囲外として見落とされがち |
IT部門担当者の次の一手は、稼働中システムの構成要素（OS・ミドルウェア・組み込みライブラリ）の棚卸しリストを作り、発行年を問わずKEVカタログと突合する仕組みを持つことだ。決裁側にとっての判断材料は、その棚卸し作業を内製化するか、保守委託先のSLAに脆弱性管理の範囲として明記し直すかという、費用と責任分界点の見極めになる。
まとめ
CISAが2026年8月26日に追加した6件のうち5件は、発行から4年から11年が経過した「古いCVE」だった。パッチが存在する脆弱性であっても、何年も前のバージョンのまま放置されたシステムが実際に狙われ続けている。IT部門担当者の次の一手は、資産棚卸しの対象を直近発行分だけに絞らず、稼働中の全資産へ発行年を問わず広げることだ。決裁側にとっての判断材料は、その棚卸しを内製するか委託先の契約に明記するかという役割分担の見直しになる。「枯れたシステムだから安全」という前提を、いつ見直すかが問われている。
よくある質問（FAQ）
Q. 古いCVEが今になってKEV入りするのはよくあることか？
A. 珍しいことではない。CISAは公開時点で悪用の証拠がなくても、後の脅威インテリジェンス分析で悪用が判明すればKEVへ追加する。発行年の新旧はKEV入りするかどうかの判断基準にはならない。
Q. 自社にRed Hat libuserやABRTが入っているか、どう確認すればよいか？
A. 稼働中のLinuxディストリビューションのパッケージ管理システム（rpm -qやdpkg -lなど）で対象パッケージのインストール状況とバージョンを確認できる。組み込み製品の場合はベンダーへの問い合わせが必要になることもある。
Q. すべての資産を発行年を問わず棚卸しするのは現実的か？
A. 一度に全システムを網羅する必要はない。まずは基幹システムや外部公開しているシステムから優先的に、稼働コンポーネントの一覧化とKEVカタログとの定期突合を始めるのが現実的だ。
出典
[1] https://www.cisa.gov/news-events/alerts/2026/08/26/cisa-adds-six-known-exploited-vulnerabilities-catalog[2] https://thehackernews.com/2026/08/cisa-adds-six-exploited-flaws-to-kev.html
[3] https://www.infosecurity-magazine.com/news/cisa-kev-microsoft-citrix/
[4] https://www.cve.org/CVERecord?id=CVE-2015-5287
