CVE-2026-116066 in Firecrawl
Summary
by MITRE • 10/25/2026
Firecrawl before 2.11.586 contains a server-side request forgery vulnerability in the Playwright service SSRF proxy that allows attackers to bypass isInternalHost checks via DNS rebinding. Attackers controlling DNS for a scrape target can return a public address during validation and a private address at connect time, retrieving cloud metadata and internal resources through the scrape API.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in Firecrawl versions prior to 2.11.586 represents a critical server-side request forgery flaw within its Playwright service proxy mechanism. This issue stems from an insufficient validation of host addresses during network requests initiated by the application. Specifically, the system employs isInternalHost checks designed to prevent access to private or internal IP ranges that are not intended for external exposure. However, this security control relies on a static resolution model where the hostname is resolved and validated at the time of initial request submission. This approach fails to account for dynamic changes in DNS records between the moment of validation and the actual network connection establishment, creating a window of opportunity for exploitation through DNS rebinding techniques.
DNS rebinding attacks exploit this timing discrepancy by allowing an attacker who controls the domain associated with the scrape target to manipulate DNS responses dynamically. During the initial phase when Firecrawl performs its internal host check, the Domain Name System returns a public IP address that appears safe and passes the isInternalHost validation logic. Once the connection attempt begins or during subsequent steps of the request lifecycle, the attacker alters the DNS record for the same domain to resolve to an internal private IP address, such as those found in cloud metadata endpoints like 169.254.169.254 or other local network services. Because the application has already authorized the hostname based on its initial public resolution, it proceeds with the connection without re-verifying the actual destination IP, thereby bypassing the security boundary entirely.
The operational impact of this vulnerability is severe, as it enables unauthorized access to sensitive internal resources that are typically isolated from external networks. Attackers can leverage this flaw to retrieve cloud metadata containing authentication tokens, credentials, and configuration details essential for further compromise of the underlying infrastructure. Additionally, the ability to reach internal services allows for potential lateral movement within a network environment or interaction with vulnerable internal applications such as administrative panels, databases, or IoT devices that may be exposed via the proxy. This effectively neutralizes perimeter defenses relying on IP-based filtering and exposes critical assets to remote exploitation without requiring direct access to the target's private subnet.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically illustrating how improper validation of user-supplied input can lead to unauthorized internal network access. It also maps to MITRE ATT&CK technique T1504.003 Web Service Discovery, as the attacker uses the SSRF vector to probe and identify services running on internal hosts. Furthermore, the specific mechanism of DNS rebinding relates to CWE-295 Improper Certificate Validation in a broader sense of trust management failures, although it is primarily an input validation flaw regarding network destinations.
To mitigate this risk, organizations must implement robust defense-in-depth strategies that go beyond simple hostname checks. The most effective mitigation involves validating the resolved IP address at multiple stages of the request lifecycle, including after DNS resolution and before establishing the TCP connection. Implementing strict allowlists for outbound connections ensures that only explicitly approved destinations are accessible. Additionally, deploying network-level controls such as egress filtering can prevent requests from reaching internal subnets regardless of application-layer validation failures. Updating to Firecrawl version 2.11.586 or later resolves this issue by addressing the underlying logic flaws in the Playwright service proxy's handling of DNS resolutions and host validations.