GitHub Repo
Firecrawl 社群回報 DNS 重綁缺口，Playwright 抓取代理可能連入內網
10 月 20 日的 Firecrawl 社群回報指出，Playwright 抓取服務的 DNS 檢查與實際連線分開解析，可能讓請求繞過內網位址限制。同日已有固定解析結果的草稿修補，但尚未合併，雲端服務是否受影響仍待確認。
Firecrawl 的 GitHub 社群於 10 月 20 日公開一項 Playwright 抓取服務安全回報：用來阻擋伺服器端請求偽造（SSRF）的代理，可能因兩次 DNS 解析結果不同，讓原本通過檢查的外部網址連入部署環境內網。回報者標示已確認的 main 分支提交，但未提供完整受影響版本清單；公開重現步驟則註明須另行索取。問題回報
問題出在檢查與使用位址的時間差。依回報，isInternalHost() 先解析主機名稱，判斷目的地是否為內部位址；通過後，底層 proxy-chain 又以同一主機名稱建立連線，觸發另一次解析。若目標網域的 DNS 由攻擊者控制，兩次回覆便可能先給公網位址、再給私有位址。回報者指出，另一條 safeFetch 路徑會在 TCP 連線時驗證實際遠端位址，並無相同缺口。技術說明
同日提出的草稿 PR #5261，改為讓連線沿用已檢查的 DNS 結果，透過自訂 dnsLookup 避免再次取得未核准位址。提案附有代理層回歸測試，作者表示六項測試通過，涵蓋重綁情境與內部位址拒絕；這仍是提案者的驗證結果，尚不能視為正式發布的修復。修補提案
對把網頁抓取接入 RAG 或代理流程的團隊而言，技術意義在於：工具接受的網址，也決定服務能接觸哪些網路資源。Firecrawl 官方自架文件確認預設堆疊包含 Playwright 處理，並要求公開部署前加入驗證、網路存取控制及 TLS；這提供部署背景，並非對此次缺口的官方確認。自架文件
後續應追蹤維護者審查、正式修復版本與實際引擎配置。草稿也明列限制：設定 PROXY_SERVER 時，目標解析交由上游代理，仍須由上游執行出口政策。截至查核時，PR 尚為草稿，作者亦未確認託管服務是否使用該引擎，因此不能將回報直接擴大為所有 Firecrawl 雲端用戶均受影響。修補範圍與限制