FlareSolverr is a browser proxy with no default API authentication

FlareSolverr is a proxy server that launches a browser to handle Cloudflare and DDoS-GUARD challenges. It is designed for integrations such as Jackett, where a client needs a browser session and cookies to reach another site. The service's API can create and destroy browser sessions, submit requests, and return page data. That is a powerful outbound-network capability, not a harmless health endpoint.

The FlareSolverr issue tracker has documented deployments where the service was reachable on a public port without API authentication. The maintainer documentation and issue discussion describe the same architectural fact: the service does not provide a built-in authentication layer for its API. The operator must place it on a private network or behind a trusted access control.

The zero-count lesson

On 2026-11-08 between 07:54 and 07:55 Asia/Shanghai, the count-only probes used sub_type=all, page 1, and page size 1. app="FlareSolverr", title="FlareSolverr", and port="8191" && title="FlareSolverr" each returned 0.

Those zeros do not establish that no FlareSolverr instances are reachable. They establish that these three candidate fingerprints did not match in this scope at that time. The service may return a generic page title, sit behind a reverse proxy, use a different port, or appear only after a POST request. A responsible conclusion is "no match for these signatures," not "zero exposed deployments."

Why access matters

An unauthenticated caller can ask the browser proxy to fetch a URL and may be able to retain cookies or session state. That can make the service useful for SSRF, for bypassing network restrictions, or for consuming the operator's resources. The outbound request originates from the FlareSolverr host, so an application allow-list at the caller does not automatically protect the destination network.

The service may also expose browser challenge artifacts, response bodies, and cookies in its API response. A public listener can therefore disclose content that the operator assumed was protected by the upstream site. The browser's network path and DNS resolver are part of the security boundary.

Review checklist

Bind FlareSolverr to loopback or a private management interface. Require an authenticated reverse proxy to reach it, and test from outside that proxy. Restrict egress to the destinations the integration needs. Block link-local addresses, metadata services, internal administrative ranges, and arbitrary DNS resolution unless the use case explicitly requires them.

Set request and session limits. Clean up browser sessions and avoid retaining cookies longer than necessary. Log the caller identity, destination host, response status, and session lifecycle without recording full response bodies or credentials. Update the browser and the proxy service together because the attack surface includes both components.

Defensive baseline

Treat FlareSolverr as an internal outbound browser. It should not be internet-facing, even if its API returns no obvious login page. The ZoomEye zeros are an invitation to verify the actual host inventory and private network paths, not a claim that the deployment is absent.

References

• FlareSolverr README
• FlareSolverr issue: unauthenticated API exposure