2026年2Q KEVカタログ掲載CVEの統計と分析

Share
2026年2Q KEVカタログ掲載CVEの統計と分析アイキャッチ画像

前回記事では、米CISAから公開された「KEVカタログ(Known Exploited Vulnerabilities)」へ2026年第1四半期(1Q)に追加された脆弱性を統計的に分析し、実際に悪用された脆弱性から見える攻撃傾向について解説しました。本記事では、2026年4月1日から6月30日までにKEVカタログへ追加された脆弱性を対象に、前回四半期との比較を交えながら、2026年第2四半期(2Q)に見られた特徴を整理します。

2026年2四半期(2Q)の統計データ概要

2026年2QにKEVカタログへ追加された脆弱性は75件でした。2026年第1四半期(1Q)と比較すると4件増加しており、件数だけを見ると大きな変化ではありません。しかし、KEVは「実際に悪用されたことが確認された脆弱性」を掲載するカタログであるため、追加件数の増減以上に「どのような脆弱性が追加されたのか」を見ることが重要です。

月別では追加件数にばらつきが見られ、一時的な集中というよりは、四半期を通じて継続的に新たな悪用事例が確認されたことが分かります。

月別のKEV追加件数

追加件数構成比
4月3141.3%
5月2128.0%
6月2330.7%

このことは、攻撃者が特定の大型脆弱性だけを狙うのではなく、新たに公開された脆弱性や過去の脆弱性を継続的に攻撃対象へ組み込んでいることを示唆しています。

主要ベンダー別の内訳

KEVへ追加された脆弱性をベンダー別に見ると、複数の脆弱性が同一ベンダーへ集中しているケースが確認されました。一方で、2026年2Qの特徴は、特定ベンダーへの極端な集中というよりも、ネットワーク機器、リモート管理ツール、業務システム、Webアプリケーションなど、幅広い製品群に悪用対象が広がっていることです。

企業が保有するIT資産は多様化しており、攻撃者もそれに合わせて侵入口を分散させています。そのため、「Microsoft製品だけを優先する」「VPN製品だけを重点管理する」といった限定的な運用では十分とは言えません。

ベンダー別KEV追加件数(上位10社)

順位ベンダーQ2件数Q1件数増減
1Microsoft1512+3
2Cisco74+3
3SimpleHelp30新規
3Ubiquiti30新規
3Ivanti32+1
3Adobe30新規
7LiteSpeed20新規
7Oracle20新規
7Google23-1
7BerriAI20新規

特に管理用途で利用される製品やインターネットへ公開される機器は、侵害された場合の影響が大きく、継続して攻撃対象となっています。

脆弱性タイプ(CWE)の分布

CWE件数
CWE-22(パストラバーサル)6
CWE-20(不適切な入力検証)5
CWE-94(コードインジェクション)5
CWE-287(不適切な認証)5
CWE-306(重要な機能の使用に対する認証の欠如)4
CWE-502(不適切なデータ逆シリアル化)3
CWE-78(OSコマンドインジェクション)3
CWE-284(不適切なアクセス制御)3
CWE-89(SQLインジェクション)3

KEVに追加された脆弱性をCWE別に分類すると、依然として攻撃者が初期侵入に利用しやすい脆弱性が多く確認されました。代表的な脆弱性として以下が上位を占めています。

  • OSコマンドインジェクション
  • 認証回避
  • 不適切な認可
  • パストラバーサル
  • リモートコード実行(RCE)

これらはいずれも、攻撃者が認証前または低権限の状態からシステムへ侵入し、その後の権限昇格や横展開につなげやすい脆弱性です。特に認証回避や認可不備は、CVSSスコア以上に実運用への影響が大きく、VPN機器や管理画面、リモート保守製品などで繰り返し悪用されています。

脆弱性の種類を見ると、「攻撃者が最初にシステムへ入り込むための入り口」が依然として重点的に狙われていることが分かります。

攻撃の自動化容易性(Automatable)

2026年第2Qも、自動化が容易である「Yes」と評価された脆弱性が一定数確認されました。攻撃者は現在、脆弱性を発見すると短期間でスキャンツールへ組み込み、インターネット上の対象を広範囲に探索するケースが一般的です。認証回避やリモートコード実行(RCE)の脆弱性は、PoC(概念実証コード)が公開されると、数日から数週間で大規模なスキャンの対象になることも珍しくありません。

企業側としては、「実際に狙われてから対応する」のではなく、自動化攻撃の対象になり得る脆弱性については、公開直後から迅速なパッチ適用や緩和策の実施を検討する必要があります。

CVSSスコア分布‐CVSSだけでは優先順位は決められない‐

重大度Q2件数Q2構成比Q1件数
Critical(9.0~10.0)2736.0%30
High(7.0~8.9)3850.7%34
Medium(4.0~6.9)1013.3%7
Low/None00%0

KEVへ登録された脆弱性のCVSSを集計すると、CriticalとHighを合わせて全体の約87%を占めました。これは高リスク脆弱性が多いことを示していますが、一方でMedium評価の脆弱性もKEVへ登録されています。つまり、CVSSがそれほど高くなくても、実際に悪用されれば優先的な対応対象になるという点が、KEVの大きな特徴です。

CVSSは技術的な深刻度を示す指標ですが、攻撃者が利用するかどうかまでは評価していません。そのため、脆弱性管理ではCVSSとKEVを組み合わせて優先順位を判断することが重要になります。また、現在はCVSS v3.xとCVSS v4.0が混在しており、単純なスコア比較には注意が必要です。評価体系が異なるため、スコアだけで危険性の増減を判断すべきではありません。

実際にランサムウェア攻撃に悪用された脆弱性

2026年第2Qでは、12件(全体の16.0%)の脆弱性でランサムウェアとの関連が確認されました。件数だけを見ると全体の一部に見えますが、ランサムウェア攻撃で利用される脆弱性は、侵入後に高い権限を取得できるものや、企業ネットワーク全体へ影響を及ぼしやすいものが多い点に注意が必要です。

一方で、「Unknown」と分類された脆弱性は、「ランサムウェアでは利用されていない」という意味ではありません。現時点で公開情報から確認できていないことを示しており、今後の調査やインシデント分析によって状況が変わる可能性があります。

第1四半期(1Q)との比較

追加件数だけを見ると、2Qは1Qから大きく増加したわけではありません。しかし、登録された脆弱性の内容を見ると、いくつかの特徴が見えてきます。

まず、攻撃対象が特定のベンダーに集中するのではなく、ネットワーク機器やリモート管理ツール、業務システム、Webアプリケーション、開発環境など、多様な製品へ広がっている点が挙げられます。また、認証回避や認可不備といった初期侵入につながる脆弱性が引き続き多く確認されました。こうした傾向からは、攻撃者が新たな攻撃手法を次々と生み出すというよりも、既知の脆弱性を効率的に悪用し、侵入の足掛かりとして利用している状況がうかがえます。

さらに、KEVには公開から時間が経過した脆弱性も継続して追加されています。これは、攻撃者が古い脆弱性を積極的に狙っているというよりも、パッチ未適用のシステムやサポート終了製品が依然として運用されている実態を反映している可能性があります。脆弱性が公表されてから時間が経過していても、適切な更新が行われていなければ、引き続き攻撃対象となることを示していると言えるでしょう。

統計から見える3つのポイント

2026年2QのKEVを俯瞰すると、特に注目すべき点は次の3つです。

攻撃対象の分散

従来は特定ベンダーのゼロデイ脆弱性が大きく注目されることがありましたが、第2四半期は幅広い製品が攻撃対象となりました。企業は個別製品への対応だけでなく、自社が保有する資産全体を把握した上で、継続的に脆弱性を管理する必要があります。

自動化攻撃への対応

Automatableと評価された脆弱性は、公開後短期間で大規模なスキャンの対象になる可能性があります。攻撃が始まってから対応するのではなく、KEVへの追加を一つの判断材料として優先的に対処することが重要です。

CVSSだけでは優先順位を決められない

高いCVSSスコアを持つ脆弱性への対応はもちろん重要ですが、実際に攻撃で悪用されているという事実は、運用上さらに重要な意味を持ちます。KEVは、その「実際の悪用」という観点を補完する情報源として活用できます。

まとめ

2026年2Qは、件数そのものよりも、攻撃対象の多様化や、自動化しやすい脆弱性、認証回避など初期侵入を容易にする脆弱性が継続して悪用されている点が特徴的でした。これらは特定の業種や製品に限った問題ではなく、多くの組織が共通して直面するリスクと言えるでしょう。定期的にKEVの追加状況を確認し、自社資産との照合やパッチ適用の優先順位付けへ活用することは、限られたリソースで効果的な脆弱性管理を実施するための重要な取り組みとなります。

件数や分類だけでは、実際の攻撃者がどのような製品を標的とし、どのような脆弱性を悪用しているのかまでは見えてきません。実際に攻撃で悪用された事例の分析については以下の記事をご覧ください。
2026年2Q KEVカタログに見る攻撃トレンド ― 実際に悪用された脆弱性から読み解く攻撃者の狙い

【参考情報】

編集責任:木下


BBSecでは

アタックサーフェス調査サービス

インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報(OSINT)を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。


サイバーインシデント緊急対応

セキュリティインシデントの再発防止や体制強化を確実に行うには、専門家の支援を受けることも有効です。BBSecでは緊急対応支援サービスをご提供しています。突然の大規模攻撃や情報漏洩の懸念等、緊急事態もしくはその可能性が発生した場合は、BBSecにご相談ください。セキュリティのスペシャリストが、御社システムの状況把握、防御、そして事後対策をトータルにサポートさせていただきます。

サイバーセキュリティ緊急対応電話受付ボタン
SQAT緊急対応バナー

ウェビナー開催のお知らせ

  • 2026年8月19日(水)14:00~15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―
  • 2026年8月26日(水)「AI時代に見直すセキュリティ対策 ~ASMの考え方で始める攻撃対象領域の可視化とリスク対策~
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    CWE Top 25 2025年版(後編)– メモリ安全性が上位に増えた理由と対策の要点

    Share
    CWE Top 25 2025年版– メモリ安全性が上位に増えた理由と対策の要点アイキャッチ画像

    CWE Top 25:2025」では、もう一つ見逃せない特徴があります。それが、メモリ領域の安全性に関わる弱点が複数上位に含まれている点です。本記事では、CWE Top 25 2025年版で目立つメモリ系弱点を整理したうえで、なぜ上位に増えているのか、Webサービス運用の観点でどのように備えるべきかを解説します。

    はじめに:前編の振り返り(Web/API 12項目)

    前編では、CWE Top 25 2025年版のうち、WebアプリケーションやAPIで特に問題になりやすい弱点をピックアップし、リスクと診断観点を整理しました。具体的には、XSSやCSRFといった入力・リクエスト起点の脆弱性に加え、「認可の欠如不備」のようにログインしていても不正操作が成立するタイプの脆弱性が、実被害につながりやすいポイントとして挙げられます。Web/APIは機能追加や仕様変更が多いため、対策しているつもりでも抜けが生まれやすく、定期的な点検が重要です。

    前編の記事はこちらからご覧いただけます。
    CWE Top 25 2025年版(前編)– Web/APIで狙われやすい弱点12項目と診断ポイント」(https://www.sqat.jp/kawaraban/41257/

    前編で取り上げたWeb/APIの脆弱性は、日々の開発や運用の中で発生しやすく、脆弱性診断でも頻出する領域です。一方で、CWE Top 25 2025年版を俯瞰すると、もう一つ見逃せない特徴があります。それが、メモリ領域の安全性に関わる脆弱性が複数上位に含まれている点です。

    メモリ系の脆弱性は、C/C++など低レベル言語で起きやすい印象が強く、「Webアプリ中心の開発では関係が薄い」と思われることもあります。しかし実際には、Webサービスを支える基盤やOSS、ミドルウェア、各種ライブラリにはネイティブ実装が含まれることも多く、アプリケーションの外側でリスクが顕在化するケースも少なくありません。また、メモリ破壊系の脆弱性は、単なるサービス停止(DoS)に留まらず、条件次第では任意コード実行など深刻な侵害につながる可能性があります。攻撃の影響が大きく、対応にも専門性が求められることから、近年あらためて注目されている領域といえます。

    そこで後編では、CWE Top 25 2025年版で目立つメモリ系弱点を整理したうえで、なぜ上位に増えているのか、Webサービス運用の観点でどのように備えるべきかを解説します。

    メモリ領域の安全に関する脆弱性が上位に増えている理由

    CWE Top 25 2025年版ではメモリ安全性に関わる脆弱性が複数ランクインしている傾向もみてとれます。一見すると「これはC言語など低レベル言語の話で、Webアプリ開発とは関係が薄いのでは?」と思われるかもしれません。しかし実際には、Webサービスを提供する側にとっても無視できないテーマになっています。ここでは、2025年版で目立つメモリ系の脆弱性と、上位に増えている背景を整理します。

    2025年に目立つメモリ系6項目

    CWE Top 25 2025年版の中で、特にメモリ領域の安全性に関連する項目としては以下が挙げられます。

    1. CWE-787:範囲外の書き込み
    2. CWE-416:解放したメモリの使用
    3. CWE-125:範囲外の読み取り
    4. CWE-476:NULLポインター逆参照
    5. CWE-121:スタックベースバッファオーバーフロー
    6. CWE-122:ヒープベースバッファオーバーフロー

    これらは主にC/C++言語などで発生しやすい脆弱性で、メモリ破壊を起点としてアプリケーションの異常動作やクラッシュ、条件次第では任意コード実行にまでつながる可能性があります。

    メモリ系が“ランク上昇”した背景

    OSS・ミドルウェア・実行環境の影響が大きい

    近年のシステム開発では、自社でゼロからすべてを実装することはほとんどありません。
    Webアプリケーション自体は高水準言語(Java、PHP、Python、Ruby、JavaScriptなど)で書かれていたとしても、実際には裏側で多くのソフトウェア資産に依存しています。 例えば、以下のような領域はネイティブ実装(C/C++など)が含まれることが多く、メモリ安全性の影響を受けやすい代表例です。

    • 画像・動画の変換や解析
    • 圧縮・解凍処理
    • 暗号処理
    • OSやコンテナの周辺コンポーネント
    • Webサーバやロードバランサなどの基盤ソフトウェア

    つまり「アプリはWebだからメモリ破壊は関係ない」と切り分けるのではなく、サービス全体を構成する要素としてメモリ安全性の弱点が影響し得る、という視点が必要になります。

    「攻撃が成立した時のインパクト」が大きい

    メモリ破壊系の脆弱性は、単にアプリがダウンする(DoS攻撃等の影響による)だけでなく、条件がそろうと攻撃者にとって非常に強力な結果につながることがあります。たとえば、任意コード実行や権限奪取の足がかりになるケースもあり、被害の深刻度が高くなりやすい点が特徴です。

    Webアプリケーションの脆弱性は「データが漏れる」「不正操作される」といった被害が中心になりやすい一方で、メモリ系は侵害の方向性が変わり、“システムそのものの制御”に影響する可能性がある点で性質が異なります。このインパクトの大きさが、ランキング上でも目立ちやすい要因の一つです。

    “開発者の気付き”だけでは防ぎにくい

    XSSやSQLインジェクションは、実装者の意識と共通部品の整備で減らしていける領域です。一方でメモリ安全性の弱点は、そもそも自社コードではなく、依存しているライブラリやミドルウェアの脆弱性として露出することも少なくありません。この場合、開発者が気を付けて実装していても防ぎきれず、必要になるのは次のような対策です。

    • 利用コンポーネントの把握(棚卸し)
    • 脆弱性情報の継続的な収集
    • バージョンアップ・パッチ適用の判断と運用
    • 影響範囲の評価(どの機能が影響を受けるか)

    つまり、メモリ系の脆弱性は「作り込みで防ぐ」だけではなく、運用で守る力も問われる領域だと言えます。

    脆弱性対応は「作り込み」+「運用」の両輪

    Webアプリケーションのセキュリティ対策というと、入力チェックや認可実装など“作り込み”に注目が集まりがちです。もちろんこれは重要ですが、メモリ系の弱点が示すように、脆弱性対応には運用面の強さも求められます。

    運用面で意識したいポイントは、以下のように整理できます。

    • 利用しているライブラリ/ミドルウェアの把握(棚卸し)
    • 脆弱性情報の継続的な収集と影響評価
    • パッチ適用・アップデートの判断と実施
    • 監視・ログによる異常兆候の検知
    • 必要に応じた防御策(WAFなど)による被害軽減

    特に「アップデートできる体制があるか」「影響範囲を素早く見積もれるか」は、脆弱性が公開された際の対応スピードに直結します。メモリ系の脆弱性は影響が大きくなりやすい分、発覚後の初動が被害を左右するため、日頃から“運用で守る仕組み”を整えておくことが重要です。

    脆弱性診断でどう確認するか(診断観点の例)

    メモリ領域の安全性の脆弱性は、Web/APIの脆弱性とは性質が異なり、「画面やAPIを触るだけでは見えにくい」ケースもあります。そのため、脆弱性診断ではアプリケーションの挙動確認に加えて、実装・構成・依存関係といった複数の観点からリスクを洗い出すことが有効です。

    Webアプリケーション診断/API診断

    実際の画面・APIに対して攻撃パターンを当て、脆弱性が成立するかどうかを確認します。
    メモリ系の弱点そのものを直接検出するのは難しい場合もありますが、前編で整理した認可不備・IDOR・SSRF・ファイル関連など、実被害につながりやすい脆弱性を網羅的に確認できる点が強みです。

    ソースコード診断(SAST)

    危険な実装パターンや、入力値の扱い方、権限判定の実装の偏りなどを、コードレベルで洗い出せる手法です。メモリ領域の安全性の観点でも、ネイティブコードを含む箇所や危険APIの利用状況、例外処理の不足などを確認することで、潜在的なリスクを把握しやすくなります。特に、開発を継続しながら対策を積み上げる場合、設計や共通部品の見直しにも活用できます。

    プラットフォーム診断/OSS観点(依存関係・構成)

    メモリ系の脆弱性を含む“依存資産のリスク”に対応するには、構成・依存関係の観点が欠かせません。アプリケーションの外側に原因がある場合、どれだけアプリの実装を直してもリスクが残るためです。「脆弱性が出たときに、すぐ把握できる・すぐ対応できる」状態を作ることが、結果的にリスクを下げる近道になります。

    まとめ

    CWE Top 25 2025年版から読み取れるのは、Webアプリ・APIで頻出する脆弱性が依然として事故につながりやすい一方で、メモリ安全性のように“アプリの外側”に潜むリスクも無視できない存在になっているという点です。この2つを両立できるかどうかが、2025年のセキュリティ対策の分かれ道になると言えます。

    “定期的な診断+改善”でリスクを下げる

    脆弱性対策は、一度対応して終わりではなく、仕様変更・機能追加・依存資産の更新によって状況が変化します。だからこそ、CWE Top 25のような指標を参考にしながら、第三者視点の脆弱性診断で現状を確認し、優先度を付けて改善していくことが有効です。Webアプリケーション診断・API診断・ソースコード診断を組み合わせることで、「攻撃が成立するポイント」と「根本原因」を整理しやすくなり、修正の手戻りを減らしながら安全性を高められます。継続的な診断と改善を通じて、インシデントの予防と品質向上につなげていきましょう。

    BBSecでは

    「どこが危ないのか」を把握しないまま対策を進めると、重要な弱点が残ったり、修正の手戻りが増えたりすることがあります。Webアプリケーション/APIの脆弱性診断により、実際に攻撃が成立するポイントを洗い出し、優先度を付けて改善につなげることが可能です。まずは現状の課題や診断範囲について、お気軽にご相談ください。

    限定キャンペーン実施中!

    ソースコード診断 アップチャージプランのご案内

    Web診断に加えて、アプリケーション内部の脆弱性を確認できるソースコード診断(アップチャージプラン)もご用意しています。

    詳細・お申し込みボタン

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    CWE Top 25 2025年版(前編)– Web/APIで狙われやすい弱点12項目と診断ポイント

    Share
    「CWE Top 25 2025年版(前編)– Web/APIで狙われやすい弱点12項目と診断ポイント」アイキャッチ画像

    2025年12月、MITREより「CWE Top 25:2025」が公開されました。本記事では、CWE Top 25 2025年版のうち、WebアプリケーションやAPIに直結する12項目をピックアップし、リスクと診断観点を整理します。

    CWE Top 25とは

    Webアプリケーションや業務システムを狙った攻撃は年々巧妙化していますが、実は“よく悪用される脆弱性”には一定の傾向があります。限られた工数の中で効果的に対策を進めるには、脆弱性を闇雲に潰すのではなく、被害につながりやすい弱点から優先して対応することが重要です。そこで参考になるのが、MITREが公開している「CWE Top 25」です。CWE(Common Weakness Enumeration、共通脆弱性タイプ)は、ソフトウェアに潜む弱点を体系的に整理したもので、CWE Top 25はその中でも特に危険度が高く、実際の攻撃にもつながりやすい弱点をランキング形式でまとめたものです。開発・運用の現場で「どこから手を付けるべきか」を判断するための指標として活用できます。

    CWE Top 25は毎年アップデートされるため、年ごとの傾向を追うことで「長年狙われ続けている脆弱性」や「新たに注目されているリスク」も見えやすくなります。2024年版の内容は過去記事でも解説していますので、あわせてご覧ください。
    【CWE TOP 25 2024年版】にみる新たなセキュリティ脅威と指針」(https://www.sqat.jp/kawaraban/33156/

    CWE Top 25 2025年版

    順位CWE ID脆弱性名称
    1CWE-79入出力の不適切な無害化(クロスサイトスクリプティング(XSS))
    2CWE-89SQLコマンドの特殊要素の不適切な無害化(SQLインジェクション)
    3CWE-352クロスサイトリクエストフォージェリ(CSRF)
    4CWE-862認可の欠如
    5CWE-787範囲外の書き込み
    6CWE-22制限ディレクトリへのパス制限不備(パストラバーサル)
    7CWE-416解放したメモリの使用
    8CWE-125範囲外の読み取り
    9CWE-78OSコマンドで使用される特殊要素の不適切な無効化(OSコマンドインジェクション)
    10CWE-94コード生成の不適切な制御(コードインジェクション)
    11CWE-120入力サイズチェックなしのバッファコピー(古典的バッファオーバーフロー)
    12CWE-434危険なタイプのファイルのアップロード許可
    13CWE-476NULLポインター逆参照
    14CWE-121スタックベースバッファオーバーフロー
    15CWE-502不適切なデータ逆シリアル化
    16CWE-122ヒープベースバッファオーバーフロー
    17CWE-863不適切な認可
    18CWE-20不適切な入力検証
    19CWE-284不適切なアクセス制御
    20CWE-200権限を持たないユーザへの機密情報の漏洩
    21CWE-306重要な機能の使用に対する認証の欠如
    22CWE-918サーバサイドリクエストフォージェリ(SSRF)
    23CWE-77コマンドで使用される特殊要素の不適切な無害化(コマンドインジェクション)
    24CWE-639ユーザ制御キーによる認可バイパス
    25CWE-770制限やスロットリングなしのリソース割当

    Web/APIに直結する“狙われやすい12項目”

    CWE Top 25 2025年版には、メモリ安全性の弱点など幅広い項目が含まれていますが、脆弱性診断会社の視点で特に注目したいのは、WebアプリケーションやAPIに直結し、実被害につながりやすい脆弱性です。Web/APIは外部からアクセス可能な入口が多く、仕様変更や機能追加も頻繁に発生します。その結果、実装ミスや設計の抜けが生まれやすく、攻撃者にとっても狙いやすい領域になりがちです。ここでは、Top 25のうちWeb/APIに絡む以下の12項目をピックアップし、リスクと脆弱性診断の観点を整理します。

    Web/APIで特に重要な12項目一覧

    1. CWE-79
    2. CWE-352
    3. CWE-862
    4. CWE-22
    5. CWE-434
    6. CWE-863
    7. CWE-20
    8. CWE-284
    9. CWE-200
    10. CWE-306
    11. CWE-918
    12. CWE-639

    入力・出力の不備(攻撃の入口になりやすい)

    CWE-79:クロスサイトスクリプティング(XSS)

    コメント欄のような分かりやすい入力欄だけでなく、検索結果、プロフィール、管理画面のメモ欄など「入力した内容が表示される場所」全般が対象になります。XSSが成立すると、セッション情報の窃取によるアカウント乗っ取り、偽画面による情報詐取、管理者権限での操作悪用などにつながる可能性があります。特に管理画面で発生した場合、被害が大きくなりやすい点が特徴です。

    脆弱性診断では、入力点の洗い出しに加え、“どこで入力が表示されるか(出力箇所)” を意識して確認します。実装側で「入力チェックをしている」つもりでも、表示時のエスケープが不十分なケースは多く、テンプレートの扱いや出力文脈(HTML/属性/JavaScript)まで含めた確認が重要になります。

    SQAT.jpでは過去にもクロスサイトスクリプティングについて、初心者向けの解説記事を公開しています。こちらもあわせてご覧ください。
    クロスサイトスクリプティング(XSS)の脆弱性 -Webアプリケーションの脆弱性入門 1-」(https://www.sqat.jp/tamatebako/27269/

    CWE-20:不適切な入力検証

    入力検証不備は、受け取った値が想定どおりかどうかの確認が不足している状態です。一見すると地味な問題に見えますが、WebアプリやAPIでは、入力値がそのままDB検索、権限判定、外部連携、ファイル処理などに渡ることが多く、他の脆弱性の引き金になりやすい“起点”です。特にAPIでは、フォーム入力だけでなくJSON形式のリクエスト、配列やネスト構造、数値・文字列の型違いなど、入力のバリエーションが増えます。その結果、「画面側では弾けているのにAPI直叩きで通ってしまう」「境界値や異常値で想定外の挙動になる」といった事故が起きやすくなります。

    脆弱性診断では、正常系だけでなく、境界値・異常系・型違い・過剰な長さ・未定義パラメータなどを含めて入力を揺さぶり、想定外の処理やエラー露出が起きないかを確認します。

    リクエスト偽装・処理のすり抜け(攻撃者が「操作」を作る)

    CWE-352:クロスサイトリクエストフォージェリ(CSRF)

    CSRFは攻撃者が用意したページやリンクを踏ませることで、ユーザ本人が操作したように見えるリクエストが送信され、設定変更や登録情報更新などが実行されてしまう可能性があります。特に危険なのは、パスワード変更、メールアドレス変更、権限変更、退会処理など「状態を変える操作」です。攻撃が成立しても操作主体が正規ユーザに見えるため、被害に気づきにくい点もCSRFの厄介なところです。

    脆弱性診断では、重要操作にCSRFトークンが実装されているか、SameSite属性が適切か、Origin/Refererの扱いがどうなっているかなどを確認します。SPAやAPI中心の構成では「CSRFは関係ない」と思われがちですが、認証方式によっては成立するため、設計前提から整理して確認することが重要です。

    SQAT.jpでは過去にもクロスサイトリクエストフォージェリについて、初心者向けの解説記事を公開しています。こちらもあわせてご覧ください。
    クロスサイトリクエストフォージェリ(CSRF/XSRF)とは?狙われやすいWebアプリケーションの脆弱性対策」(https://www.sqat.jp/tamatebako/12249/

    CWE-918:サーバサイドリクエストフォージェリ(SSRF)

    SSRFは、サーバ側が外部へアクセスする仕組みを悪用され、攻撃者が任意の宛先にリクエストを送らせる脆弱性です。たとえば「指定したURLから画像を取得する」「外部APIのURLを登録する」といった機能がある場合、入力値の制御が不十分だとSSRFにつながる可能性があります。SSRFが危険なのは、外部から直接アクセスできない内部ネットワークや管理系サービスに到達できてしまう点です。環境によっては、クラウドのメタデータ(認証情報)取得など、重大な侵害につながるケースもあります。

    脆弱性診断では、URL入力や外部通信の機能を洗い出し、許可リスト制御があるか、名前解決やリダイレクトがどう扱われるか、内部アドレス(localhostやプライベートIP)へのアクセスが可能かなどを確認します。外部連携機能は便利な反面、攻撃の入口になりやすいため、重点的な確認が必要です。

    認証・認可の不備(ログインしていても守れていない)

    CWE-306:重要な機能の使用に対する認証の欠如

    重要な機能の使用に対する認証の欠如は、本来ログインが必要な操作が、認証なしで実行できてしまう状態です。代表例としては、管理者向けのAPIや運用機能が「画面からは触れない」ために見落とされ、URL直叩きで実行できてしまうケースが挙げられます。 この弱点があると、攻撃者はアカウントを用意する必要すらなく、いきなり機能を悪用できてしまいます。影響範囲は機能次第で、情報閲覧だけでなく、設定変更やデータ削除などにつながる可能性もあります。

    脆弱性診断では、ログイン前に到達できるURL・APIを洗い出し、認証が正しくかかっているかを横断的に確認します。特に、管理系の機能や“メンテナンス用”に追加されたエンドポイントは、抜けが起きやすいポイントです。

    CWE-862:認可の欠如

    認可の欠如は、「ログインしているユーザが、その操作をしてよいか」の判定が不足している状態です。認証が正しく実装されていても、認可が抜けていると、一般ユーザが管理機能を実行できたり、他人の情報にアクセスできたりするリスクが生まれます。現代のWebアプリはAPI化が進み、画面とAPIが分離されているケースも多くあります。その結果、「画面上ではボタンが表示されないが、APIを直接叩くと通ってしまう」といった問題が発生しやすくなります。認可は“画面制御”ではなく“サーバ側判定”が必須です。

    脆弱性診断では、ユーザ権限を切り替えながら同じAPIを試す、IDを変更して他人データに触れないか確認するなど、権限境界を意識したテストを行います。認可不備は事故につながりやすい一方で見落とされやすいため、重点的に確認すべき項目です。

    CWE-863:不適切な認可

    誤った認可は、認可チェック自体は存在するものの、判定条件が不十分・誤っている状態です。たとえば「ロール(一般/管理者)は見ているが、所属組織や契約単位の制御が抜けている」「閲覧は制御できているが更新だけ抜けている」など、複雑な仕様ほど起きやすい傾向があります。このタイプの問題は、単純な“認可チェックの抜け”よりも発見が難しく、機能仕様を理解したうえでテストしないと見落とされがちです。結果として、公開後に利用者からの指摘やインシデントで発覚することもあります。

    脆弱性診断では、ロールだけでなく、組織・契約・所有権などの境界を整理し、境界を跨ぐ操作ができてしまわないかを確認します。実装だけでなく、設計段階での権限モデルの整理が重要になります。

    CWE-284:不適切なアクセス制御

    不適切なアクセス制御は、認証・認可・制限の仕組み全体が適切に機能していない状態を指す、非常に重要なカテゴリです。CWE-862やCWE-863、CWE-639などと密接に関係し、実際のインシデントでは“アクセス制御の穴”としてまとめて問題になるケースも少なくありません。アクセス制御の難しさは、実装ミスだけでなく、仕様変更や機能追加によって整合性が崩れやすい点にあります。APIが増えるほど確認対象も増え、権限チェックの一貫性を保つのが難しくなります。

    脆弱性診断では、画面・API・直接URLアクセスなど複数経路からの到達性を確認し、「見えないはずの機能が触れてしまう」「アクセスできないはずの情報が見えてしまう」といった問題を洗い出します。アクセス制御は“守りの土台”であり、最優先で見直すべき領域です。

    CWE-639:ユーザ制御キーによる認可バイパス

    ユーザ制御キーによる認可バイパスは、ユーザが指定できるIDやキーを悪用し、認可を回避できてしまう問題です。いわゆるIDOR(Insecure Direct Object Reference)として知られるケースが多く、例えば「注文ID」「請求書ID」「ユーザID」などを変更するだけで他人の情報にアクセスできてしまうといった形で発生します。この脆弱性が厄介なのは、画面上では正しく動いて見えることが多い点です。正規ルートでは問題がなくても、パラメータを改ざんすると成立してしまうため、悪意ある操作を前提にした確認が欠かせません。

    脆弱性診断では、IDやキーを意図的に変更し、他人データの閲覧・更新・削除ができないかを確認します。設計としては、IDを推測しにくくするだけでなく、サーバ側で必ず所有権チェックを行うことが重要です。

    情報の露出(「次の攻撃」の起点になる)

    CWE-200:権限を持たないユーザへの機密情報の漏洩

    機密情報の露出は、権限のない相手に情報が見えてしまう状態です。例としては、APIレスポンスに不要な項目が含まれている、エラーメッセージに内部情報が出ている、管理画面の情報が一般ユーザから参照できる、といったケースが挙げられます。情報漏洩は、それ単体でも重大な事故ですが、攻撃者にとっては“次の攻撃を成功させる材料”になります。たとえば、ユーザ情報や内部構成が漏れることで、なりすましや権限突破、別の脆弱性悪用が容易になることがあります。

    脆弱性診断では、画面表示だけでなくAPIレスポンスの内容、エラー出力、ログ出力の扱いまで含めて確認します。「返さなくてもよい情報を返していないか」を見直すことは、対策コストに対して効果が大きいポイントです。

    ファイル・パスの取り扱い(“便利機能”が事故の原因になる)

    CWE-22:パストラバーサル

    パストラバーサルは、ファイル・パスの指定を悪用され、想定外のファイルにアクセスされてしまう脆弱性です。例えば、ダウンロード機能や画像表示機能で、パラメータがそのままファイル・パスに使われている場合に発生しやすく、設定ファイルや機密ファイルの閲覧につながる可能性があります。この問題は、アプリケーション内部の設定情報や秘密鍵などの露出を招くことがあり、被害が“情報漏えい”に留まらず、侵入やなりすましの起点になることもあります。

    脆弱性診断では、パス指定のパラメータを揺さぶり、制限ディレクトリ外の参照ができないかを確認します。設計としては、ファイルはIDで管理し、サーバ側で実体パスに変換する方式が安全です。

    CWE-434:危険なタイプのファイルのアップロード許可

    危険なファイルアップロードは、攻撃者が悪意あるファイルをアップロードできてしまう脆弱性です。拡張子チェックだけで判定している場合、実体がスクリプトや実行形式であってもすり抜けられることがあり、Webシェル設置やマルウェア配布などにつながる危険があります。また、アップロードしたファイルがそのまま公開ディレクトリに置かれている場合、アクセスされるだけで攻撃が成立するケースもあります。ファイル機能はユーザにとって便利な一方で、攻撃者にとっても“侵入口”になりやすい領域です。

    脆弱性診断では、アップロード可能な拡張子・MIME・実体判定、保存先、参照方法、実行可否などを確認します。特に「アップロード後にどう扱われるか(公開されるか、変換されるか)」まで含めて評価することが重要です。

    【補足】なぜこの12項目が脆弱性診断で重要なのか
    ここまで見てきた12項目は、いずれもWebアプリやAPIで発生しやすく、攻撃者が外部から試行しやすい弱点です。また、認可やアクセス制御のように、仕様・設計・実装が絡み合う領域は、チェック漏れが起きやすい一方で、発見が遅れると影響が大きくなりがちです。 そのため、開発時のレビューや自動テストだけでなく、第三者視点での脆弱性診断によって「実際に攻撃が成立するか」を確認し、優先度を付けて改善していくことが有効です。

    現場での優先度付け(Web/API向け)

    CWE Top 25に含まれる弱点は幅広く、すべてを一度に潰すのは現実的ではありません。そこで重要になるのが、「被害が大きいもの」「攻撃者が試しやすいもの」から優先して対策する考え方です。ここでは、WebアプリケーションやAPIを前提に、現場で取り組みやすい優先順位を整理します。

    認可

    まず最優先に見直したいのは、認可(Authorization)に関する脆弱性です。認証(ログイン)が正しく動いていても、「そのユーザがその操作をしてよいか」の判定が甘いと、他人の情報閲覧や不正更新、管理機能の悪用につながります。特にAPIが増えるほど、権限チェックの抜けや判定ミスが起きやすく、事故の原因になりがちです。認可の問題は、攻撃が成立すると影響範囲が大きく、かつログ上は正規ユーザの操作に見えることもあります。Web/APIにおけるセキュリティの土台として、まずは認可を最優先で点検することが重要です。

    入出力・CSRF

    次に優先したいのは、入出力の取り扱い(XSSや入力検証不備など)と、CSRFです。
    入力値は、画面表示・DB操作・外部連携など多くの処理に影響するため、わずかな実装ミスが攻撃の入口になりやすい領域です。またXSSは、利用者のアカウント乗っ取りや管理画面の悪用につながる可能性があり、優先度の高い脆弱性です。CSRFについても、状態変更系の操作(変更・更新・削除)がある限り、対策の抜けがあると被害につながります。「ログインしているから安全」ではなく、“正しい意図の操作かどうか”を担保できているかを確認する必要があります。

    SSRF・ファイル関連

    SSRFやファイル関連の脆弱性は、システムに該当機能がある場合、優先度を一段階上げて確認すべき項目です。たとえば、URL入力を受け付ける機能(外部連携、Webhook、画像取得など)がある場合、SSRFが成立すると内部ネットワークへのアクセスや情報取得につながる可能性があります。また、ファイルアップロード/ダウンロード機能がある場合は、危険なファイルの混入やパストラバーサルによる情報漏えいなど、攻撃の入口になりやすい要素が揃っています。利便性の高い機能ほどリスクも増えやすいため、仕様として存在するなら“重点確認対象”として扱うのが安全です。

    情報露出・認証の欠如

    最後に、見落とし厳禁として挙げたいのが「情報露出」と「認証欠如」です。機密情報の露出は、単体でも重大な事故ですが、攻撃者にとっては次の攻撃を成立させるための材料にもなります。APIレスポンスの過剰返却やエラーメッセージの出し方など、“つい残ってしまう情報”が原因になることも少なくありません。また、重要機能の認証欠如は、成立すると攻撃者がログインすらせずに機能を悪用できてしまいます。管理用のエンドポイントや運用機能など、「利用者が限られるから大丈夫」と思われがちな部分ほど抜けが起きやすいため、公開前後での棚卸しが重要です。

    Web/APIは定期診断が有効

    Web/APIは機能追加や仕様変更が多く、開発時点で対策していたとしても、改修のたびに新しい抜けが生まれる可能性があります。だからこそ、開発段階での対策に加えて、第三者視点の脆弱性診断で「実際に攻撃が成立するか」を確認し、優先度を付けて改善することが効果的です。定期的に診断を実施することで、仕様変更による取りこぼしを早期に発見し、インシデントを未然に防ぐことにつながります。

    後編では、CWE Top 25 2025年版で目立つもう一つのポイントとして、メモリ領域の安全に関わる脆弱性が上位に増えている背景を整理します。なぜ今メモリ系が注目されているのか、どのように備えるべきかを、診断・運用の観点も含めて解説します。


    ―後編に続く―

    BBSecでは

    「どこが危ないのか」を把握しないまま対策を進めると、重要な弱点が残ったり、修正の手戻りが増えたりすることがあります。Webアプリケーション/APIの脆弱性診断により、実際に攻撃が成立するポイントを洗い出し、優先度を付けて改善につなげることが可能です。まずは現状の課題や診断範囲について、お気軽にご相談ください。


    限定キャンペーン実施中!

    今なら新規お申込みで 初回診断料金 10%OFF
    短期間での診断が可能な「SQAT® with Swift Delivery」で、あなたの企業をサイバー脅威から守りませんか?

    詳細・お申し込みボタン

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    CVEとは?共通脆弱性識別子の基本と管理方法を徹底解説

    Share

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    お問い合わせ

    お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。

    はじめに

    情報セキュリティにおいて“CVE”は必ずといっていいほど登場するキーワードです。本記事では「CVEとはなにか?」という基本的な疑問に答えながら、脆弱性管理の観点で知っておきたいCVE番号の仕組みや運用方法を解説します。

    CVEの概要

    • CVE(Common Vulnerabilities and Exposures) は、ソフトウェアやハードウェアの脆弱性に一意の識別番号を付与する仕組みです。
    • 米国政府支援のMITRE社が運営し、世界中のセキュリティ関係者が共通の脆弱性情報を参照できます。 (CVE – Mitre, Common Vulnerabilities and Exposures)
    • 目的:脆弱性情報の共有とトラッキングを標準化し、誤解や情報の断絶を防ぐこと。

    CVE識別子の構造

    CVE番号は以下のような形式を取ります。

    例:CVE-2025-22457

    項目説明
    プレフィックスCVE一意の脆弱性識別子の接頭辞
    発行年2025脆弱性が登録された西暦年
    識別番号22457当該年に発行された通し番号

    CVEの仕組みと運用フロー

    1. 発見・報告
      セキュリティリサーチャーやベンダーが脆弱性を発見し、MITREに報告
    2. 分析・番号割当
      MITREが報告内容を審査し、CVE番号を割り当て
    3. 公表・共有
      NVD(National Vulnerability Database)や各国CERTなどで情報公開
      (Vulnerabilities – NVD – National Institute of Standards and Technology)
    4. 対応策検討
      ベンダーは修正プログラム(パッチ)を開発・公開
    5. 適用・監視
      利用者はCVE番号を基にリスク評価し、パッチ適用や対策を実施

    CVE情報の取得方法

    CVEを活用した脆弱性管理

    1. 脆弱性スキャンとの連携
      スキャンツールが検出した脆弱性にCVE番号を紐付け、一覧化
    2. 優先順位付け(プライオリティ設定)
      CVSSスコア(Common Vulnerability Scoring System)や影響範囲から対応の緊急度を判断 (Common Vulnerability Scoring System SIG)
    3. パッチ管理プロセス
      定期的にCVEリストを更新し、パッチ適用状況を追跡
    4. 報告・監査
      CVE番号を用いたレポートでセキュリティ監査に対応

    よくある質問(FAQ)

    Q1. CVEとCWEの違いは?

    • CVE:脆弱性そのものを識別する番号
    • CWE:脆弱性の種類や原因を分類する共通項目(例:CWE-79=クロスサイトスクリプティング) (Common Weakness Enumeration: CWE – Mitre)

    Q2. CVE番号はどこで確認できる?

    Q3. CVE情報の更新頻度は?

    • NVDは原則毎日更新
    • 各ベンダーは脆弱性発見後数日〜数週間でアドバイザリ公開

    まとめ

    CVEは、全世界で共通の脆弱性識別子として脆弱性管理の基盤を支えています。番号の仕組みや運用フローを理解し、定期的に情報を取得・対応することで、自社システムのセキュリティを大幅に向上させることが可能です。まずはNVDやJPCERT/CCを定期チェックし、CVE番号による脆弱性トラッキングを始めましょう。

    【参考情報】

    以上の参考情報を活用し、CVEを軸とした脆弱性管理を強化していきましょう。

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    ウェビナー開催のお知らせ

  • 2025年5月21日(水)14:00~15:00
    Webサイト改ざん攻撃の手口と防御策とは?リアルタイム検知で守るセキュリティ
  • 2025年5月28日(水)13:00~14:00
    脆弱性診断の新提案!スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー
  • 2025年6月4日(水)13:00~14:00
    知っておきたいIPA『情報セキュリティ10大脅威 2025』~セキュリティ診断による予防的コントロール~
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像