GitHub Repo
Firecrawl Community Reports DNS Rebinding Gap That Could Let Playwright Scraping Proxy Reach Internal Networks
A Firecrawl community report on October 20 said the Playwright scraping service resolves DNS separately for its checks and its actual connection, potentially allowing requests to bypass internal-address restrictions. A draft fix that reuses the checked DNS result was proposed the same day but has not been merged. Whether the hosted service is affected remains unconfirmed.
On October 20, the Firecrawl GitHub community published a security report about its Playwright scraping service: a proxy designed to block server-side request forgery (SSRF) could, because of differing results from two DNS lookups, allow an external URL that passed the check to connect to an internal network in the deployment environment. The reporter identified a confirmed commit on the main branch but did not provide a complete list of affected versions. The public reproduction steps say they are available upon request. Issue report
The issue lies in the time gap between checking an address and using it. According to the report, isInternalHost() first resolves the hostname and checks whether the destination is an internal address. After the check passes, the underlying proxy-chain establishes a connection using the same hostname, triggering another lookup. If an attacker controls the target domain’s DNS, the two responses could return a public address first and a private address second. The reporter noted that another path, safeFetch, validates the actual remote address when the TCP connection is made and does not have the same gap. Technical details
A draft PR, #5261, proposed the same day changes the connection to reuse the DNS result that was checked, using a custom dnsLookup to avoid retrieving an unapproved address again. The proposal includes regression tests at the proxy layer. Its author said all six tests passed, covering rebinding scenarios and rejection of internal addresses. This is the proposer’s test result and should not be taken as a fix officially released by the project. Proposed fix
For teams integrating web scraping into RAG or agent workflows, the technical implication is that the URLs a tool accepts also determine which network resources the service can reach. Firecrawl’s official self-hosting documentation confirms that the default stack includes Playwright processing and calls for authentication, network access controls, and TLS before public deployment. This provides deployment context; it is not official confirmation of this specific gap. Self-hosting documentation
Next, track maintainer review, an officially fixed release, and the actual engine configuration. The draft also states a limitation: when PROXY_SERVER is configured, target resolution is delegated to the upstream proxy, which must enforce its own egress policies. At the time of checking, the PR was still a draft, and the author had not confirmed whether the hosted service uses that engine. The report therefore cannot be generalized to mean that all Firecrawl cloud users are affected. Fix scope and limitations