GitHub Repo
Firecrawl Merges DNS Rebinding Fix, Playwright Proxy Connections Pinned to Verified Addresses
On October 21, Firecrawl merged a fix that closes an SSRF bypass path caused by two DNS lookups in its Playwright service. Deployments using an upstream proxy still need to restrict egress separately; the status of release packages and hosted service deployments remains unconfirmed.
On October 21, Firecrawl merged PR #5261 into its main branch, fixing a gap in server-side request forgery (SSRF) protections for its Playwright crawling service. For deployments that use a browser to fetch web pages for proxies or RAG, the change affects whether the crawling service can be induced to access internal networks. Merge record
The issue arose because the target domain was resolved separately during validation and connection setup. The protection first checked the destination address, but the underlying proxy resolved the domain again when establishing the connection. A changed DNS response could therefore redirect the connection to an internal network. The update pins the connection to an address that passed validation in the same DNS lookup, narrowing the gap between the validated result and the actual destination. The fix also adds a proxy-layer reproduction test. Fix details
The protection still has configuration boundaries. When PROXY_SERVER is set, the upstream proxy resolves the target domain, and this change cannot pin the destination address for that path; egress policy remains the upstream proxy’s responsibility. The behavior that disables checks when ALLOW_LOCAL_WEBHOOKS=true also remains unchanged. What is confirmed so far is that the code has been merged; that alone does not establish that all release packages or cloud service deployments have been updated. Configuration limits
Self-hosting teams in particular should verify the image and source version actually running. Firecrawl’s official documentation says self-hosters are responsible for upgrades, security, and monitoring, and that crawling makes outbound requests. Its quickstart configuration is limited to trusted networks and should not be treated as a production architecture. Self-hosting documentation
The next engineering step is to confirm which proxy the browser worker actually uses, which layer resolves the target domain, and whether the fix is included in the version in use. For AI data pipelines that accept arbitrary URLs, this also highlights the need to combine application-level validation with network egress restrictions; OWASP’s SSRF Prevention Cheat Sheet likewise lists both as defense layers. OWASP guidance