Exploit Databaseとは？特徴5つとエントリの見方を解説

Exploit Database（Exploit DB）は、既知の脆弱性に対するエクスプロイトやPoC（概念実証コード）を集めた公開データベースです。
セキュリティ研究者やペネトレーションテストの担当者だけでなく、自社システムを守る情報システム担当者にとっても、脆弱性対応の優先度を判断する手がかりになります。

この記事では、Exploit Databaseの目的や5つの特徴、エントリページの読み方、防御側の活用手順と注意点をわかりやすく解説します。

Exploit Databaseとは

運営元と収録されている情報

Exploit Database（Exploit DB）は、既知の脆弱性に対するエクスプロイト（悪用コード）やセキュリティリサーチを広く公開するデータベースです。
セキュリティ研究者、システム管理者、ペネトレーションテストの専門家などに利用される、オープンで広範なリソースとして知られています。

運営しているのは、ペネトレーションテスト向けのLinuxディストリビューション「Kali Linux」の開発元としても知られるOffensive Security（現OffSec）です。
収録されているのは、脆弱性を悪用するためのコードやPoC、対象となるソフトウェアとバージョンの情報、技術的な解説などです。

Exploit DBが扱うのは、すでに公開された既知の脆弱性です。未知の脆弱性（ゼロデイ）を事前に知るための場所ではなく、公開済みの脆弱性が、どこまで具体的に悪用できる状態にあるかを確認するための情報源と考えるとわかりやすいでしょう。

NVDやベンダー情報との役割分担

脆弱性の情報源には、Exploit DBのほかに、米国NISTが運営する脆弱性データベースNVDや、日本のJVN、製品ベンダーが公開するセキュリティアドバイザリなどがあります。
それぞれ得意とする情報が異なるため、役割を分けて組み合わせることが脆弱性対応の精度を高めるポイントです。

情報源	主にわかること
NVD・JVN	脆弱性の概要、CVE番号、CVSSによる深刻度
ベンダーのセキュリティアドバイザリ	影響を受けるバージョン、修正版、回避策
Exploit Database	公開されている悪用コードやPoC、攻撃が成立する条件の手がかり

どれか一つの情報源だけで判断を完結させないことが大切です。NVDやベンダー情報で「何をどう直すか」を確認し、Exploit DBで「どの程度悪用の手がかりが出回っているか」を補うという使い分けが実務では安定します。

Exploit Databaseの目的と利用用途

主な4つの利用目的

Exploit DBは、主に次の4つの目的で利用されています。立場によって使い方は異なりますが、いずれも既知の脆弱性をより深く理解するという点で共通しています。

脆弱性情報の共有

Exploit DBは、脆弱性に関するエクスプロイト情報を共有し、開発者やセキュリティ担当者がシステムの脆弱性に対処するための情報を提供します。どの脆弱性に悪用コードが出回っているかがわかるため、既知の脅威に対する防御策の強化につながります。

ペネトレーションテストの支援

セキュリティ専門家やペネトレーションテストの担当者は、Exploit DBを使用して、特定の脆弱性を持つシステムのテストを行います。実際のエクスプロイトコードを参考に検証することで、潜在的なリスクを評価し、セキュリティの改善につなげることができます。

セキュリティ研究の支援

セキュリティリサーチャーは、Exploit DBの情報を参考に脆弱性の原因や悪用の仕組みを研究し、攻撃シナリオの分析や防御策の開発に役立てています。過去のエクスプロイトを分析することで、同じ種類の欠陥が別の製品で生まれていないかを調べる手がかりにもなります。

教育・人材育成

Exploit DBは、セキュリティ教育の一環として利用されることもあります。学習者が実際のエクスプロイトコードを読み解き、脆弱性の原理や攻撃手法を理解するための教材として活用されています。

Exploit Databaseの特徴

誰でも無料で閲覧できる

Exploit DBは、誰でもアクセスできるオープンなプラットフォームとして提供されています。登録不要でエクスプロイト情報を閲覧できるため、セキュリティコミュニティで広く利用されています。

裏を返せば、攻撃者も同じ情報を自由に参照できるということです。防御側にとっては、攻撃者が手に入れられる情報を同じ目線で確認できる点に価値があります。

幅広い分野のエクスプロイトを収録

Exploit DBには、Webアプリケーション、ネットワーク機器、オペレーティングシステム、各種ソフトウェアなど、幅広い分野のエクスプロイトが収録されています。
古い製品から比較的新しい製品まで対象が広いため、サポートが終了した製品を使い続けているシステムのリスク確認にも役立ちます。

条件を指定して検索できる

利用者は、脆弱性の種別、対象のソフトウェア、プラットフォーム、CVE番号、公開日など、さまざまな条件でエクスプロイトを検索できます。自社で使っている製品名やバージョンで絞り込めば、関係する情報を素早く見つけることができます。

検証済みかどうかを確認できる

Exploit DBのエントリには、運営側で動作が確認されたかどうかを示す表示があります。掲載されたすべての情報が動作確認済みというわけではないため、この表示は情報の確からしさを見る目安になります。

ただし、検証済みであっても、自社の環境で同じように攻撃が成立するとは限りません。未検証のエントリも含めて、あくまで判断材料の一つとして扱うことが大切です。

Metasploitなど検証ツールとの関わり

Exploit DBに掲載されたエクスプロイトの中には、ペネトレーションテストで広く使われるMetasploit Frameworkのモジュールの元になったり、参考にされたりしているものがあります。
Metasploitの検索機能では、Exploit DBのID（EDB-ID）を手がかりにモジュールを探すこともできます。こうした関わりにより、脆弱性の情報収集から許可された範囲での検証までを効率よく進められます。

エントリページの読み方

EDB-ID・タイトル・公開日

EDB-IDは、Exploit DBが各エントリに付ける固有の番号です。社内で情報を共有したり、検証ツールで対応するモジュールを探したりするときの識別子として使えます。

タイトルには、対象の製品名やバージョン、脆弱性の種類がまとめて書かれていることが一般的です。まずはタイトルを見て、自社で使っている製品やバージョンに近いものかどうかを確かめます。

公開日は、その情報がいつ掲載されたかを示します。公開から時間が経っている場合は、すでに修正版が出ていないかをベンダー情報とあわせて確認しましょう。

種別（リモート・ローカル・Webアプリ・DoS）と対象プラットフォーム

種別は、エクスプロイトがどのような形で使われるかを表す分類です。種別によって防御側が注目すべき点も変わるため、代表的な分類と見方を整理しておきましょう。

種別	意味	防御側の見方
remote	ネットワーク経由で外部から実行できる	外部に公開しているシステムでは特に優先度が高い
local	対象システムへのログインなど、内部からの実行が前提	権限昇格につながるかを確認する
webapps	Webアプリケーションの脆弱性を突く	公開中のWebサイトや管理画面を確認する
dos	サービスを停止させる	業務が止まった場合の影響の大きさで判断する

プラットフォームは、エクスプロイトが対象とするOSや実行環境を示します。同じ製品名でも、プラットフォームが異なれば自社には当てはまらない場合があるため、あわせて確認します。

CVE番号の有無と照合の仕方

CVE番号が記載されているエントリは、NVDやJVN、ベンダー情報と照合しやすくなります。CVE番号で検索すれば、深刻度の評価や修正版の有無をすぐに確認できます。

一方で、CVE番号が付いていないエントリもあります。CVE番号がないからといって、自社に関係しないとは限りません。その場合は、製品名とバージョン、脆弱性の内容をもとにベンダー情報を確認し、自社に該当するかどうかを判断します。

PoCとエクスプロイトの違い

PoC（Proof of Concept：概念実証）は、脆弱性が実際に存在し、悪用が可能であることを示すための最小限のコードや手順です。
これに対してエクスプロイトは、脆弱性を悪用して実際に攻撃を行うためのコードや手法を指し、PoCより実用的に作り込まれていることが多いです。

どちらであっても、公開された時点で悪用の手がかりが誰でも手に入る状態になっていることに変わりはありません。PoCだから安全、エクスプロイトだから即危険と単純に決めつけず、自社の環境で成立するかどうかで考えることが大切です。

CVE・CVSS・EPSSと組み合わせた見方

CVEとCVSSでわかること

CVE（Common Vulnerabilities and Exposures）は、公開された脆弱性に付けられる世界共通の識別番号です。
CVSS（共通脆弱性評価システム）は、その脆弱性の深刻度を数値で評価する仕組みで、攻撃の難しさや影響の大きさなどをもとにスコアが算出されます。

CVSSは脆弱性そのものの深刻度を示す指標であり、実際に悪用されているかどうかまでは表しません。スコアが高くても悪用の動きがほとんどない脆弱性もあれば、中程度のスコアでも積極的に狙われる脆弱性もあります。

EPSSやKEVで悪用の現実味を補う

悪用の可能性を見積もる指標として、EPSS（Exploit Prediction Scoring System）があります。EPSSは、ある脆弱性が近い将来に悪用される確率を推定するスコアで、CVSSとあわせて使うことで優先度の判断を補えます。

また、米国CISAが公開しているKEV（Known Exploited Vulnerabilities）カタログは、実際に悪用が確認された脆弱性の一覧です。KEVに載っている脆弱性はすでに攻撃に使われているため、優先度を上げる強い根拠になります。

Exploit DBに載っていることが持つ意味

Exploit DBに掲載されているということは、その脆弱性を突くための具体的な手がかりが公開されていることを意味します。攻撃者が一から攻撃方法を考えなくても、公開情報をもとに攻撃を試みやすい状態といえます。

CVSSで深刻度を、EPSSやKEVで悪用の可能性と実績を、Exploit DBで悪用コードの公開状況を確認すると、複数の角度からリスクを見積もれます。一つの指標だけに頼らず、組み合わせて判断することが重要です。

Exploit Databaseの関連プロジェクト

searchsploitによるオフライン検索

searchsploitは、Exploit DBのデータを手元に保存して検索できるコマンドラインツールです。Kali Linuxには標準で含まれており、インターネットに接続できない検証環境でもExploit DBの情報を検索できます。

外部との通信が制限された環境で脆弱性を調べる場合や、多くの製品情報をまとめて照合したい場合に便利です。ただし、手元のデータは定期的に更新しないと古くなるため、更新の運用もあわせて考えておく必要があります。

Google Hacking Database（GHDB）

GHDBは、検索エンジンの高度な検索演算子を使って、インターネット上に意図せず公開されている情報を見つけるための検索クエリを集めたデータベースです。Exploit DBの関連プロジェクトとして公開されています。

防御側にとっては、自社のWebサイトから設定ファイルや管理画面、内部資料などが検索エンジン経由で見えていないかを確認する際の参考になります。一方で、他社のサイトの弱点を探し回るような使い方は避けなければなりません。

ShellcodesとPapers

Shellcodesは、エクスプロイトの中で実行される小さなコード（シェルコード）を集めたセクションです。Papersは、脆弱性や攻撃手法に関する技術文書や研究資料を集めたセクションで、エクスプロイトの背景を理解するのに役立ちます。

防御側の担当者が日常的に参照する機会は多くありませんが、攻撃の仕組みを学ぶ社内教育や、検知ルールを考える際の参考資料として活用できます。

防御側がExploit Databaseを活用する4ステップ

ステップ1：自社資産と照合する

最初に行うのは、Exploit DBの情報が自社で使っている製品やバージョンに当てはまるかの確認です。タイトルの深刻そうな言葉に反応するのではなく、資産台帳や構成管理の情報と照らし合わせます。

製品名の表記揺れや旧名称、エディションやビルド番号の違いにも注意が必要です。該当しなければ記録だけ残して終了し、該当すれば次のステップに進みます。そもそも自社の資産を正確に把握できていなければ、Exploit DBの情報を生かすことはできません。

ステップ2：到達性と成立条件を確認する

該当する製品があった場合は、攻撃が実際に届くかどうかと、攻撃が成立する条件を確認します。インターネットに公開されているのか、社内ネットワークに限られているのかによって、リスクの大きさは大きく変わります。

あわせて、攻撃の成立にログイン認証が必要か、特定の設定や機能の有効化が前提になっていないかを確認します。外部から届き成立条件も揃っているものは優先度を高く、内部限定で条件が厳しいものは中・低として扱うと、対応の順番を決めやすくなります。

ステップ3：パッチ・暫定策・監視から対応を決める

優先度が決まったら、具体的な対応を決めます。基本はベンダーが提供する修正版への更新（パッチ適用）ですが、業務への影響ですぐに適用できない場合もあります。

その場合は、該当機能の無効化や設定変更、アクセス元の制限、WAFやIPSのルール追加といった暫定策で、攻撃が成立する条件を先に取り除きます。あわせて関連するログの監視や検知ルールを見直し、攻撃の試みに気付ける状態を整えておきます。
パッチを適用できない期間こそ、暫定策と監視強化を組み合わせて守ることが重要です。

ステップ4：記録を残し継続して確認する

対応が終わったら、どの情報をもとにどう判断し、何を実施したかを記録に残します。判断の根拠が残っていれば、同じ脆弱性について新しい情報が出たときにも素早く見直すことができます。

脆弱性情報は日々追加されるため、一度確認して終わりではありません。公開システムや認証基盤、ネットワークの境界機器など、侵害されたときの影響が大きい資産を中心に、定期的に確認する運用を続けましょう。

Exploit Databaseの利用上の注意点

法律の範囲内で利用する

Exploit DBで提供されるエクスプロイトは、セキュリティの研究やペネトレーションテストの目的で利用されることを意図しています。悪意のある目的での使用は法律違反となるため、正当な範囲内での利用が求められます。

日本では、許可なく他人のシステムに侵入する行為は不正アクセス禁止法に抵触するおそれがあります。検証を行う場合は、自社が管理するシステムか、管理者から書面で許可を得たシステムに限定しましょう。

情報の鮮度を確認する

脆弱性の情報は日々更新されているため、常に最新の情報を確認することが重要です。古いエクスプロイトの中には、すでにベンダーの修正で対策済みのものもあります。逆に、古い情報であっても、修正版を適用していないシステムが残っていれば今も有効な攻撃手段になり得ます。

本番環境では試さない

実際のエクスプロイトコードを利用する場合、対象のシステムに影響を与える可能性があるため、テスト環境での実施が推奨されます。サービスの停止やデータの破損につながるおそれもあるため、本番環境から切り離した仮想マシンや検証用ネットワークを使いましょう。

検証の目的は攻撃を成功させることではありません。自社の構成で攻撃が成立するか、どのログに痕跡が残るか、暫定策で防げるかを確かめることに絞りましょう。

偽PoCや不審なコードに注意する

公開されているPoCやエクスプロイトの中には、悪意のあるコードが紛れ込んでいるものもあります。セキュリティ担当者や研究者を狙い、PoCに見せかけたマルウェアを配布する手口も確認されています。

入手したコードは、実行する前に内容を読んで処理を理解し、必ず隔離された環境で扱いましょう。Exploit DB以外のコード共有サイトなどで公開されているものは、特に慎重な確認が必要です。

社内の利用ルールを決めておく

Exploit DBの情報やエクスプロイトコードを業務で扱う場合は、社内で利用ルールを決めておくことが大切です。誰が閲覧・検証できるのか、どの環境で検証するのか、結果をどう記録・共有するのかを明確にしておきます。

ルールがないまま個人の判断で検証を進めると、誤って本番環境に影響を与えたり、意図せず第三者のシステムに接続したりする危険があります。

Exploit Databaseに関するよくある質問

Q１. Exploit Databaseは無料で使えますか？

はい、誰でも無料で閲覧できます。アカウント登録も不要で、Webサイトから製品名やCVE番号などで検索できます。

Q.２掲載されている脆弱性はすぐに悪用されますか？

掲載されていることが、すぐに自社が攻撃されることを意味するわけではありません。ただし、悪用の手がかりが公開されている状態のため、自社に該当する場合は優先度を上げて対応を検討すべきです。

Q.３ CVE番号がないエントリは無視してよいですか？

無視はおすすめできません。製品名とバージョンをもとにベンダー情報を確認し、自社に該当するかどうかで判断しましょう。

Q４. 一般企業の情報システム担当者も見るべきですか？

すべての情報を追う必要はありませんが、自社で使っている主要な製品については確認する価値があります。脆弱性対応の優先度を決める判断材料の一つとして活用できます。

Q５. 掲載されているコードを社内で試してもよいですか？

社内ルールで許可された範囲で、本番環境から切り離した検証環境に限って扱うべきです。コードの内容を事前に確認し、第三者のシステムには決して使用しないでください。

まとめ

Exploit Database（Exploit DB）は、既知の脆弱性に対するエクスプロイトやPoCを集めた公開データベースです。

エントリの種別やCVE番号、検証状況を読み取り、CVSSやEPSS、KEVとあわせて見ることで、自社が優先すべき脆弱性を見極めやすくなります。活用する際は、自社資産との照合から対応、記録までの流れを決め、法律と社内ルールの範囲内で安全に扱いましょう。