# Firecrawl: a DNS rebinding bypass sends its scraper to internal services

> Firecrawl's scraper could be pointed at a deployment's internal network with a DNS record that changed between the check and the connection.

- **Severity:** High: A working attack on a widely used AI product or ecosystem. A fix may exist. Patch or mitigate this week.
- **Category:** Vulnerability
- **Published by:** Firecrawl
- **Disclosed:** 2026-10-20
- **CVE:** CVE-2026-116066
- **CVSS:** 7
- **Affects:** Firecrawl
- **Research by:** [carfeii](https://github.com/carfeii)
- **Primary source:** https://github.com/firecrawl/firecrawl/issues/5256
- **Page:** https://theinjection.dev/items/firecrawl-playwright-ssrf-dns-rebinding/

Firecrawl before 2.11.586 let an authenticated API caller reach internal services and cloud metadata, because its Playwright SSRF proxy checked a hostname's address and then resolved the hostname again at connect time.

## What happened

Server-side request forgery in Firecrawl's Playwright service was reported by the GitHub user carfeii on October 20, 2026, in issue 5256 on the project's repository. Firecrawl merged a fix into its main branch the next day, and NVD and the GitHub Advisory Database published the flaw as CVE-2026-116066 on October 25. The reporter's GitHub profile describes the account as a machine account maintained by a human, exploring how vulnerability discovery and disclosure will work in future.

## How it works

DNS rebinding is the technique. Firecrawl's SSRF proxy resolved a target hostname once in isInternalHost to decide whether the address was internal, and the proxy-chain library then resolved the same hostname again when it opened the connection. An attacker who controls DNS for a submitted hostname can answer the first lookup with a public address and the second with a private one, which the reporter says a record with a time to live of zero achieves. Firecrawl's separate safeFetch helper avoids the gap by checking the socket's remote address at connect time.

## Who is affected

Deployments running a Firecrawl version before 2.11.586 are affected, and the advisory records the flaw against the project rather than a published package. Any authenticated API caller, including a free-tier account, could reach loopback addresses, cloud metadata endpoints and other services on the deployment's network, and read the responses. Firecrawl describes itself in its README as the context API for AI agents, and can be self-hosted.

## What to do

Update Firecrawl to 2.11.586 or later, the first version the advisory lists as fixed. Operators who set PROXY_SERVER should note that the fix pins no lookup on that path, so the upstream proxy has to enforce its own egress policy. Review scrape logs for submitted hostnames that resolved to internal or metadata addresses.

## Quick facts

- **Affected:** Firecrawl before 2.11.586
- **Fixed in:** 2.11.586 per the advisory, merged as commit 5e74ff3 on October 21, 2026
- **CVE:** CVE-2026-116066, CVSS 7.0 high (NVD)
- **Attack type:** SSRF protection bypass by DNS rebinding (CWE-918)
- **Found by:** carfeii, reported October 20, 2026
- **Status:** Fixed in main; CVE published October 25, 2026

## Questions

### Is my Firecrawl deployment affected by CVE-2026-116066?

Firecrawl deployments running a version before 2.11.586 are affected. The flaw sits in the Playwright service that renders pages for the scrape API, so a deployment that uses that service is exposed. The reporter wrote that any authenticated API caller, including a free-tier account, could use the bypass to reach internal addresses on the deployment's network and read the responses.

### How do I fix the Firecrawl SSRF bypass?

Updating to Firecrawl 2.11.586, the first version the advisory lists as fixed, closes the bypass. The merged fix resolves a target hostname once, rejects non-unicast addresses and pins the connection to the address it checked. Operators who set PROXY_SERVER get no pinned lookup on that path, so the upstream proxy must enforce its own egress policy.

### What could an attacker reach through the Firecrawl flaw?

Cloud metadata endpoints, loopback addresses and other services on the Firecrawl deployment's network were reachable, and the responses came back through the scrape API. The GitHub Advisory Database describes the impact as retrieval of cloud metadata and internal resources. Reaching any of it required the attacker to control DNS for a hostname submitted to the scrape API.

### Did Firecrawl's existing SSRF protection not stop this?

Firecrawl had already hardened the Playwright service against SSRF, and the reported issue is titled as a bypass of that hardening. The proxy checked whether a hostname resolved to an internal address, but did not hold the connection to the address it had checked. A separate helper in the same codebase, safeFetch, already validated the socket's remote address at connect time.

## Sources

1. [Issue Report](https://github.com/firecrawl/firecrawl/issues/5256)
2. [GitHub Advisory](https://github.com/advisories/GHSA-xmmq-vp8j-m5qf)
3. [Fix Pull Request](https://github.com/firecrawl/firecrawl/pull/5261)