XSSスキャナーDalfoxに認証なしRCE CVE-2026-45087、v2.13.0へ即更新を

セキュリティ研究者やバグバウンティハンターが「他人の脆弱性を探す道具」として広く使っているXSSスキャナーDalfoxに、CVSS最高値の10.0となる脆弱性CVE-2026-45087が見つかりました。2026年5月27日にプロジェクトメンテナのhahwul氏がGitHub Security Advisory（GHSA-v25v-m36w-jp4h）として開示し、v2.13.0で修正されました。

最大の皮肉は構造です。「他人のWebアプリのXSSを見つけてあげる」ためにDalfoxを動かしている研究者の側が、そのDalfoxサーバ自体を攻撃され任意コマンド実行されるという、攻守の方向が逆転する脆弱性でした。バグバウンティ参加者の作業端末や、CI/CDパイプラインに組み込まれた自動XSSチェッカーが、まるごと攻撃者のRCE経路に変わります。

問題はdalfox serverサブコマンドで起動するREST APIモードにあります。デフォルトで0.0.0.0:6664にバインドし、API keyは空文字（=認証なし）のままで起動するため、ネットワーク上の任意の相手がPOST /scanでJSONペイロードを送り込めば、その中に仕込まれたシェルコマンドがDalfoxのプロセス権限で実行されます。報告者はEmmanuel David（@drmingler）氏です。

XSSを探す側の作業環境が攻撃面に変わる

Dalfoxの構造的な皮肉は、攻撃を見つける側のために作られた道具そのものが、攻撃される側に回ってしまった点にあります。RCEを踏むのは標的の企業ではなく、診断している研究者自身です。何がどこに連鎖するのかから先に見ます。

Dalfox serverを動かしているのはセキュリティ研究者・診断ベンダー・バグバウンティハンターであり、彼らの端末そのものが特権ノードです。狙ってくる相手は同じ標的を追っている競合バグハンターが「先回り」で報告するためのレース妨害、診断会社の調査ノートとレポート草稿を欲しがる産業スパイ、診断中の顧客企業へ「正規の経路」で侵入したいランサムウェアグループ、診断インフラを長期足場にしたいAPT。彼らが取りに来るのは、まだ未公開のゼロデイPoC、顧客向け診断レポートの草稿、検証用に保存された管理者クレデンシャル、Dalfoxホストから到達できる顧客本番への接続情報、そして「次に踏めるドメインのリスト」そのものです。本CVEを踏ませた相手は、認証ゼロで POST /scan にJSONを投げるだけでDalfoxプロセスの権限で任意コマンドを走らせ、診断中の全顧客環境への足場を獲得します。研究者本人の端末1台で被害が止まらないのは、診断ホストが顧客環境への通信経路と認証情報を抱える性質を持つからです。

構造としてはセキュリティ業界向けのサプライチェーン攻撃そのもので、診断会社の作業環境が下流の顧客全社に一斉に被害を伝搬させるハブになります。CI/CDパイプラインに組み込まれているケースはさらに重く、GitHub Actionsのランナーから本番AWS/GCPクレデンシャル、社内リポジトリの読み取り権、デプロイキーが連鎖的に吸われます。IAB市場では「診断会社インフラへの侵入路」は高値で取引される定番商品で、ランサムウェアグループはそれを買って、その会社が抱える顧客全体を一斉攻撃する手口を取ります。さらに皮肉なことに、Dalfoxは「外向きに動いて結果を持ち帰る」ツールなので、デフォルト構成が無認証で 0.0.0.0 にバインドする挙動を「自分専用ローカルだから」と受け流す利用者が多く、社内ネットワーク内の同僚や、共有開発VPSの隣人からも到達されます。

スコア10.0は1ホストの陥落しやすさを測ったものですが、Dalfox serverを動かしている研究者・診断ベンダーにとっての実損は顧客から預かった未公開の脆弱性情報と診断データが他者の手に渡り、業界内での「機密を扱える事業者」という看板を失う事態です。診断会社にとって信頼の喪失は、契約継続の喪失と直結します。

Dalfoxとは何か

Dalfoxは韓国の研究者hahwul氏が開発するOSSで、Webアプリに対するXSS（クロスサイト・スクリプティング）を自動で探し回るスキャナーです。GitHub Star数は5,000超、バグバウンティの世界ではamassやnucleiと並んで「最初に走らせるツール」のひとつとして広く採用されています。

主な使われ方は次の通りです。

• バグバウンティハンターが対象サイトに対しdalfox url ...で単発スキャン
• セキュリティ会社が顧客の診断業務で常時動かすREST APIサーバとしてdalfox serverモードで運用
• CI/CDパイプライン（GitHub Actions、GitLab CI）に組み込み、リリース前に自動XSSチェック
• ChatGPTやClaude Codeのようなツールから呼び出して、AIアシスタント経由でセキュリティテスト自動化
• パラメータ探索、WAFフィンガープリンティング、複数フォーマット（JSON / SARIF / Markdown / TOML）出力で診断レポートに直接組み込み

問題が起きたのは、上記のうち「常時動かすREST APIサーバ」として運用しているケースです。CLIで単発実行している場合は今回の脆弱性の影響を受けません。

CVE-2026-45087の中身

脆弱性は4つの設計選択が重なって生まれました。NVDの分類はCWE-78（OSコマンドインジェクション）、CWE-306（重要機能の認証欠落）、CWE-15（システム設定の外部制御）の3つを併発。

脆弱なコードパスは次の通りです。攻撃者が送ったJSONペイロードが postScanHandler() → ScanFromAPI() → dalfox.Initialize() → foundAction() → exec.Command() という流れでシェル実行に至ります。途中でmodel.Optionsのフィールド（FoundAction、FoundActionShell等）はサニタイズされず、攻撃者の文字列がそのままシェルコマンドの一部として実行されます。

「コマンド実行は脆弱性が見つかった時だけ走る仕組み」ですが、攻撃者は自分で用意した「反射型XSSを必ず返すサーバ」をターゲットURLに指定すれば、Dalfox側で確実に脆弱性検知が走り、結果として仕込んだコマンドが必ず実行されます。アドバイザリに示されたペイロード例は次のような形です。

{
  "url": "http://attacker-server/?q=test",
  "options": {
    "found-action": "echo owned >/tmp/dalfox_rce_marker",
    "found-action-shell": "bash",
    "use-headless": false,
    "worker": 1,
    "limit-result": 1
  }
}

この単純なリクエストだけで、Dalfoxが動いているマシン上に攻撃者の任意コマンドが落ちます。Dalfoxは多くの場合ホストの脆弱性スキャン業務のためにroot権限で動かしているケースもあり、その場合は被害が即座にホスト全体の侵害につながります。

なぜ「攻守反転」型の構図が成立してしまうのか

バグバウンティ業界では、参加者が自分の作業端末上にDalfoxやnuclei、ZAPのようなツールを常時動かし、複数の調査対象に対して並行スキャンするのが一般的な作業スタイルです。「ターゲットを見張るためのレーダー」だったはずのスキャナー自体に脆弱性があると、レーダーが逆に攻撃者の位置情報発信器に変わります。

攻撃者の動機は明確です。バグバウンティハンターの作業端末には、次のような価値の高い情報が集積しています。

• 過去のスキャン結果と、まだ報告していない脆弱性の生情報
• 複数のバグバウンティプラットフォーム（HackerOne、Bugcrowd、Synack）のAPIキー
• 顧客企業の機密情報、SSL/TLS秘密鍵、内部URLマップ
• SSH鍵やAWS認証情報、GitHubトークン、社用Slackトークン
• クライアント企業との契約NDA、未公開の侵入テストレポート

これらの情報は、攻撃者にとって「直接的な金銭的価値」と「他のバグバウンティハンターより先に脆弱性を売り抜ける情報優位」の両方を持ちます。Dalfoxを乗っ取ることは、攻撃者にとって極めて費用対効果の高い投資です。

類似のパターンは過去にもあります。Trivyの2回連続侵害やLiteLLMの認証バイパスなど、「セキュリティ・運用エンジニアが日常使うツール」が攻撃面として注目される流れは、2025年以降明確に強まっています。攻撃者にとって、防御側の道具を標的にすることは、その道具を持つ防御側のクライアント情報・顧客情報まで一気にアクセスできるという「複利的な攻撃価値」を持ちます。

いますぐやるべきこと

1. Dalfoxをv2.13.0以降にアップデート。 GitHubリリースページから取得します。Homebrew経由ならbrew upgrade dalfox、Goから直接ならgo install github.com/hahwul/dalfox/v2@v2.13.0。Snap、Nixpkgsのパッケージも更新を確認します。

2. v2.13.0以降でも、API keyを必ず設定する。 修正版でも「明示的にAPI key無しで起動する」運用は危険な状態のままです。--api-keyオプションでランダムな長い文字列を指定し、リクエスト側にX-API-Keyヘッダで渡す構成にします。

3. バインドアドレスをローカルホストに限定。 外部からアクセスする必要がない場合、--host 127.0.0.1でバインドアドレスをローカルホストに限定します。複数人で共有して使うチームなら、Tailscale等のメッシュVPN内に閉じ込めるのが安全策です。

4. ログを過去1か月分遡って点検。 Dalfoxのアクセスログで、自分のリクエスト元IP以外からのPOST /scanがないか確認します。/tmp/dalfox_rce_markerのような不審なファイル、Dalfoxプロセスが起動した子プロセスの履歴（ps / auditdログ）もチェックします。

5. Dalfoxを動かしているホスト上のクレデンシャル全件ローテーション。 該当バージョンで外部に公開されていた期間がある場合、過去のスキャン結果が漏れている前提で動きます。バグバウンティプラットフォームのAPIキー、SSH鍵、AWS/GCP/Azure認証情報、GitHubトークン、Slack/Discord webhook、すべてローテーションします。

6. CI/CDパイプラインに組み込んでいる場合、Runner設定の見直し。 GitHub Actions等でDalfoxをジョブ内で動かしている場合、ジョブごとに新しいRunnerコンテナが立ち上がる構成（ephemeral runner）になっているか確認します。長寿命Runnerで動かしている場合、Runnerの認証トークンとリポジトリ書き込み権限が攻撃者に渡る経路になります。

CISA KEVへの登録状況とハブ記事連動

2026年5月28日時点で、CVE-2026-45087はCISAのKEVカタログに未登録です。Dalfoxは攻撃ツールカテゴリにあたるため、CISA KEVの一次対象である「米連邦機関の運用環境」とは関心領域が異なります。ただし、被害規模としては「セキュリティ業界全体のエコシステム汚染」につながりうるため、KEV以外の文脈（DEF CON、Black Hat、各国CERT）での議論は活発化する可能性があります。

本サイトでは、現在攻撃中とCISAが認定したCVEの一覧をCISA KEVダッシュボード（日本語版）で随時更新しています。同種の「セキュリティツール自体への攻撃」事案は、OSSサプライチェーン・スキャナーでDalfoxを含む依存パッケージ群の現状を確認できます。

Dalfoxはv3.0.0でRustによる完全書き直しが進行中で、v2系は今後セキュリティ修正中心のメンテナンスフェーズに入る予定です。v3系への移行時には、デフォルトでバインドアドレスをローカルホストに、API key設定を必須化する選択がなされるかが、今回の事件の教訓として注目されます。

参照元

• ▸ NVD - CVE-2026-45087 Detail
• ▸ GitHub Security Advisory - GHSA-v25v-m36w-jp4h
• ▸ GitHub - Dalfox v2.13.0 Release
• ▸ Dalfox 公式リポジトリ
• ▸ CISA - Known Exploited Vulnerabilities Catalog