FirecrawlのSSRF防御をDNS再解決で回避｜更新後も上流プロキシを確認

FirecrawlのPlaywrightサービスで、DNSリバインディングによりSSRF防御を回避できるCVE-2026-116066が公表されました。VulnCheckは2026年10月25日付の勧告で2.11.586未満を対象とし、CVSS v4.0を7.0（High）と評価しています。自己ホスト環境で利用者指定のURLを処理している運用担当者は、API本体だけでなくPlaywrightサービスの修正取り込みと、実際に外部へ接続するプロキシの制限を確認してください。

問題は、URLのホスト名を検査する時点と、通信を開始する時点で別々に名前解決していたことです。検査時に公開IPでも、接続時には内部IPへ変わり得ました。修正は接続先を検証済みのDNS応答へ固定します。ただし上流プロキシを設定した経路では同じ固定が行われず、プロキシ側の出口制御が必要です。本稿ではこの構成差を軸に、更新・暫定防御・確認手順を整理します。

10月25日のCVE公表と10月21日の修正を区別する

根拠となるのはVulnCheckのCVE-2026-116066勧告、開発元リポジトリの報告と修正コードです。Issue #5256の報告者は10月20日に問題を公開し、開発元は10月21日に修正PR #5261をマージしています。CVE情報が公開された日を、問題が初めて知られた日や修正日と同一視しないでください。

勧告が示す修正版の境界は2.11.586ですが、独自ビルドや複数コンテナの構成では、表示上のバージョンだけで適用済みとは判断できません。修正コミット5e74ff37b41ac650d6bccff170a9be0a6decb946が、稼働するPlaywrightサービスへ入っているかを対応付けます。今回確認した資料には、実環境での悪用を確認したという記述はありません。公開された再現条件と、侵害が観測された事実は分けて扱います。

攻撃者に必要な条件と影響範囲

報告者の説明では、攻撃者はスクレイプ先のDNSを制御し、PlaywrightエンジンへURLを渡せるAPI利用者であることが前提です。報告は認証済みAPI利用者を想定している一方、CVEの評価ベクトルはPR:Nです。点数だけから「すべての導入で認証不要」と断定せず、自社のAPI認証、利用者への公開範囲、エンジンへの到達経路で判断してください。

成功すると、Firecrawlを動かすネットワーク上の位置から、内部管理画面、別コンテナのサービス、クラウドのメタデータなどへ要求が届き、取得内容がAPI経由で返る可能性があります。外部利用者が直接接続できない宛先へ、取得サービスを橋渡しにするSSRFです。取得できる情報は宛先側の認証やネットワーク制限にも左右され、任意の内部情報を必ず盗めるという意味ではありません。

優先度が高いのは、未信頼の利用者が任意URLを投入でき、Playwrightワーカーから業務ネットワークへ到達できる構成です。社内専用でも、外部文書や自動生成されたURLを取り込む経路があれば入力の出所を確認します。ホスト型サービスについては、公開されたコード修正だけを根拠に全顧客への配備完了を推測せず、提供元へ対象エンジンと適用状況を確認します。

DNS検査があっても防げなかった理由

修正前のisInternalHost()は、ホスト名を解決して内部向けのアドレスではないかを調べていました。しかし、許可後のproxy-chainは同じホスト名を使って接続し、その過程で再度DNSを引きます。検査結果と接続先を結び付ける仕組みがないため、異なる応答が返ると最初の判定は後続通信を保証しません。これは文字列として内部IPを入力する攻撃とは異なります。

例えば検証用ドメインが一度目には公開側のアドレスを返し、二度目には閉域の試験用サーバーを返す場合、名前自体は変化しません。許可したホスト名であっても、宛先の実体が入れ替わります。この例は仕組みを説明する仮想構成であり、本サイトが攻撃を実施した結果ではありません。防御で固定すべきなのはURLの見た目だけでなく、検証済みアドレスと接続の対応です。

開発元の修正コミットの差分では、名前解決と判定を行うヘルパーを分離し、チェックを通ったアドレスのみを返すdnsLookupを接続処理へ渡しています。公開・内部のアドレスが混在する応答や、解決失敗を許可する変更ではありません。接続の瞬間に未検証の宛先へ切り替わる余地を閉じる修正です。

更新後も分けて確認する三つの構成

第一は、上流プロキシを使わず、ローカルアクセスの例外も無効な通常経路です。修正コードでは、解決したアドレスを検査し、その結果を接続へ固定します。この構成では、Playwrightサービスの更新と再配備、検証済みの宛先以外へ接続しないことの確認が中心になります。APIのコンテナだけを入れ替えて終わらないよう、別サービスとして動く実体を特定してください。

第二はPROXY_SERVERを設定した経路です。修正コードは、上流プロキシがある場合にdnsLookupを返さず、接続先の名前解決を上流側へ委ねます。したがって、アプリ側の事前チェックを通ったことだけでは上流からの接続を保証できません。更新済みであっても、実際に宛先を解決するプロキシで、内部向け通信を拒否する出口ポリシーを確認する必要があります。

第三はALLOW_LOCAL_WEBHOOKSを有効にした構成です。修正ヘルパーではallowLocalが有効なら宛先検査を省略する分岐があります。名前にWebhookとあることだけでスクレイプ経路への影響を除外せず、実際の環境変数と呼び出し箇所を確認してください。内部向け通信が業務要件なら、公開URLの収集と同じ自由入力経路で例外を広げず、必要な宛先へ限定した別の境界を設けることを提案します。

運用担当者が進める更新と暫定防御

以下は公開資料を踏まえた本サイトの対応提案です。まず、どのWeb機能がFirecrawlへ要求し、どのワーカーがPlaywrightを使い、どのプロキシを通るかを台帳へ記録します。自己ホスト、管理委託、ホスト型サービスを分け、修正を配備する責任者を決めます。ライブラリ名を検索して見つからなかったことだけで対象外とは判断しません。

• 未信頼のURL投入を受け付ける機能を優先して確認し、適用が確認できるまで不要なスクレイプ経路を停止または利用者・接続先を制限する。
• Playwrightサービスのイメージ、ビルド元コミット、稼働中のリビジョンを対応付け、修正を含む構成へ再ビルド・再配備する。
• PROXY_SERVERとALLOW_LOCAL_WEBHOOKSの実値を確認し、上流プロキシと例外経路の防御責任を明確にする。
• 取得ワーカーから内部管理系や不要なサービスへの通信をネットワーク側でも制限し、使わないクラウド権限や資格情報を減らす。

多層防御の考え方はOWASPのSSRF防止チートシートにも示されています。業務で接続先を固定できるなら許可リストを使い、任意の外部サイトを扱うなら取得処理を隔離します。入力検査だけに依存せず、侵害時に到達できる範囲を狭める対策です。WAFで受信要求を検査することだけを、ワーカーの外向き通信制御の代わりにしないでください。

検証は成功応答より内部への未到達を見る

修正コードには、検査と接続でDNSを引き直さないこと、内部アドレスを拒否することを確認するテストが追加されています。通常のHTTP転送経路とCONNECT経路、ループバックやIPv4に対応するIPv6表現などが対象です。本サイトではコードを確認しており、提供元の試験結果を自社環境での実測とみなすものではありません。

受け入れ試験は自社管理下の隔離環境で行い、通常の公開ページが取得できることと、禁止先への通信が一度も発生しないことを別々に確認します。模擬DNSとダミーの内部サーバーを使えば、実際のメタデータや管理画面を読む必要はありません。APIがエラーを返しても、その前に内部へ届いていれば不合格です。受信側の到達記録と送信側の拒否ログを照合します。

プロキシ利用あり・なしを同じ試験結果で済ませないことも重要です。直接接続で固定が効いても、上流側の再解決が同じ条件を守るとは限りません。環境変数、イメージ、プロキシ設定を試験記録へ残し、デプロイ後の実値と比較します。通常機能を復旧するときは、閉じた経路を再び開く変更もレビュー対象にします。

今回の修正では、直接接続の宛先固定と上流プロキシ利用時の分岐がコード上で明確に分かれています。設定を変えたあとも前の試験結果を流用せず、名前解決を担う場所が変わっていないかを確認してください。これは修正の否定ではなく、修正が保証する経路を自分の構成へ対応付ける作業です。

既に公開していた環境の調査

対象構成を外部利用者へ提供していた場合は、更新作業と並行して履歴を保全します。スクレイプ要求の時刻、利用者またはAPIキーの識別子、ワーカーの処理履歴、外向き接続、プロキシと内部サービスの記録を対応付けます。DNS応答が残らない環境では、URLのホスト名だけから当時の実接続先を復元できるとは限りません。

不審なドメインへの要求だけで侵害を確定せず、その処理が内部へ到達したか、応答を返したかを調べます。内部APIや資格情報への接触が疑われたら、その対象のアクセス履歴と利用権限を確認し、影響に応じて失効や再発行へ進めます。ログがないことを被害なしの根拠にはせず、記録がある範囲と判断できない範囲を分けて内部の調査記録に残します。

今回の優先判断は、修正版の番号だけでは完結しません。未信頼の入力からPlaywrightへ到達するか、検査した宛先と接続先が一致するか、上流プロキシや例外設定で境界が変わらないかを一組で点検します。Firecrawlの修正を取り込み、接続を担う層の制限と到達試験まで確認してから、任意URLの処理範囲を戻してください。

関連記事

AIにURLを読ませると何が危険？SSRFから内部ネットワークを守る対策は、URL取得の一般的な防御を扱う解説です。今回の記事はFirecrawl固有のDNS再解決と、修正後に残るプロキシ構成の確認を扱っています。