CVE-2026-51031: FlareSolverr SSRF Vulnerability

CVE-2026-51031 Overview

CVE-2026-51031 is a Server-Side Request Forgery (SSRF) vulnerability affecting FlareSolverr versions prior to 3.4.7. The flaw resides in the /v1 API endpoint, which fails to validate or restrict user-supplied URLs before initiating outbound HTTP requests. A remote, unauthenticated attacker can abuse this behavior to force the FlareSolverr instance to issue requests to arbitrary internal or external targets. Successful exploitation exposes sensitive information from internal services, cloud metadata endpoints, and networks otherwise unreachable from the internet. The issue is classified under CWE-918: Server-Side Request Forgery.

Critical Impact
Unauthenticated remote attackers can pivot through vulnerable FlareSolverr instances to access internal-only services, exfiltrate cloud metadata credentials, and enumerate internal network resources.

Affected Products

FlareSolverr versions prior to 3.4.7
Deployments exposing the /v1 API endpoint to untrusted networks
Containerized FlareSolverr instances running in cloud environments with instance metadata services

Discovery Timeline

2026-07-20 - CVE-2026-51031 published to NVD
2026-07-21 - Last updated in NVD database

Technical Details for CVE-2026-51031

Vulnerability Analysis

FlareSolverr is a proxy server designed to bypass Cloudflare and DDoS-Guard protections by using a headless browser to solve challenges. The /v1 API endpoint accepts JSON-formatted requests that include a target URL for the underlying browser to fetch. Prior to version 3.4.7, the endpoint does not enforce an allowlist or block requests targeting internal address ranges. An attacker with network access to the FlareSolverr service can submit crafted requests that instruct the headless browser to fetch arbitrary URIs on behalf of the server.

Because the browser executes the request from the host's network context, the attacker gains an indirect channel into private networks. Responses returned by the target service are relayed back through the FlareSolverr API, giving the attacker read access to internal HTTP resources.

Root Cause

The root cause is missing input validation on the url parameter accepted by the /v1 endpoint. FlareSolverr treats any URL supplied in the request body as trusted and passes it directly to the browser engine. No filtering is applied to reject localhost, 127.0.0.0/8, RFC1918 ranges, link-local addresses such as 169.254.169.254, or non-HTTP schemes. This absence of destination validation is the defining characteristic of CWE-918.

Attack Vector

The attack requires only network reachability to the FlareSolverr HTTP listener, with no authentication or user interaction. A typical exploitation flow involves the attacker sending a POST request to /v1 with a command such as request.get and a url field pointing at an internal target. Common abuse cases include reading cloud instance metadata endpoints to steal temporary credentials, enumerating internal admin panels, and interacting with services that trust local network origin. See the GitHub SSRF Vulnerability Report for a detailed technical write-up.

Detection Methods for CVE-2026-51031

Indicators of Compromise

POST requests to the /v1 endpoint containing url values referencing 127.0.0.1, localhost, or RFC1918 address ranges
Requests targeting cloud metadata endpoints such as 169.254.169.254 or metadata.google.internal
Anomalous outbound connections from the FlareSolverr host to internal services it does not normally contact
FlareSolverr process resolving DNS names for internal-only hostnames

Detection Strategies

Inspect FlareSolverr access logs for /v1 requests with suspicious cmd and url payloads referencing internal addresses
Deploy network monitoring rules that alert when the FlareSolverr host initiates traffic toward metadata services or private subnets
Correlate web proxy telemetry with process activity on the FlareSolverr host to identify attacker-controlled request patterns

Monitoring Recommendations

Enable verbose logging on the FlareSolverr container and forward events to a centralized log platform for retention and search
Monitor egress firewall denies from the FlareSolverr host, which indicate probing for internal targets
Track version telemetry across deployed FlareSolverr instances to identify hosts still running versions prior to 3.4.7

How to Mitigate CVE-2026-51031

Immediate Actions Required

Upgrade FlareSolverr to version 3.4.7 or later on all hosts and container images
Remove any exposure of the FlareSolverr /v1 endpoint from untrusted networks and require network-level authentication
Audit cloud IAM roles attached to FlareSolverr instances and rotate any credentials that may have been exposed via metadata SSRF

Patch Information

Upgrade to FlareSolverr version 3.4.7 or later, which introduces validation on the /v1 endpoint to reject requests targeting internal and reserved address ranges. Container operators should pull the updated image and redeploy affected workloads. Refer to the GitHub SSRF Vulnerability Report for full remediation context.

Workarounds

Restrict FlareSolverr to bind on loopback interfaces only and place it behind an authenticated reverse proxy
Apply egress firewall rules that deny outbound traffic from the FlareSolverr host to RFC1918 ranges, 127.0.0.0/8, and 169.254.169.254
On cloud deployments, enforce Instance Metadata Service v2 (IMDSv2) to prevent credential theft via basic SSRF requests

bash

# Example egress restriction using iptables to block metadata and internal ranges
iptables -A OUTPUT -m owner --uid-owner flaresolverr -d 169.254.169.254 -j DROP
iptables -A OUTPUT -m owner --uid-owner flaresolverr -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -m owner --uid-owner flaresolverr -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -m owner --uid-owner flaresolverr -d 192.168.0.0/16 -j DROP