Top/Articles/Crawl4AI Vulnerabilities: Update to 0.9.2 or Later to Be Safe
crawl4ai-cve-2026-56266-cover-en

Crawl4AI Vulnerabilities: Update to 0.9.2 or Later to Be Safe

Crawl4AI, a popular crawler for AI data collection, has a critical flaw in its Docker API server, exploitable without authentication (CVE-2026-56266). An attacker can make the server fetch cloud internal data and steal access keys. All versions before 0.8.7 are affected; 0.8.7 also fixes several flaws including a pre-auth RCE. Update now.

NewsPublished June 23, 2026Last updated July 24, 2026
Table of contents
Key takeaways

Crawl4AI, a popular crawler for AI data collection, has a critical flaw in its Docker API server, exploitable without authentication (CVE-2026-56266). An attacker can make the server fetch cloud internal data and steal access keys. All versions before 0.8.7 are affected; 0.8.7 also fixes several flaws including a pre-auth RCE. Update now.

Crawl4AI, a popular open-source crawler (web-page collection tool) used to gather data for AI to learn from or reference, carries several serious flaws in every version before 0.9.0 that can be exploited without a login. The affected setup is mainly the network-exposed "Docker API server," where an outside attacker can turn the server into a springboard and steal internal-network or cloud internal data and access keys. Whether you are adopting it now or already running it, the answer for closing every flaw for sure is to update to the latest stable release (0.9.2, published July 15, 2026).

The flaw that first drew attention is CVE-2026-56266, exploitable without authentication. Its type is "SSRF (Server-Side Request Forgery)": the server fetches whatever URL it is given, so an attacker can make it reach internal-network or cloud internal resources it could not access directly. The CVSS score is 8.6 (v3.1) and 9.2 (v4.0) — both top-tier severity. It was published with advisory GHSA-365w-hqf6-vxfg in June 2026, and this flaw itself was fixed in 0.8.7.

But stopping at 0.8.7 or 0.8.9 is dangerous. Later review found a new unauthenticated SSRF (CVE-2026-57573) hitting a different Docker API server entry point, plus a flaw that lets attackers run commands on the server without login (CVE-2026-57572, CVSS 10.0) — all fixed together in 0.9.0. CVE-2026-57573 affects every version before 0.9.0 and still remains in 0.8.9. If you are upgrading now, go to 0.9.0 or later, and in production to the latest 0.9.2, to be safe.

SoftwareCrawl4AI (mainly Docker API server)
Main CVEsCVE-2026-56266 / 56265 / 53753 / 53755 / 57571 / 57572 / 57573
Highest severityCVSS 10.0 (CVE-2026-57572: unauthenticated command execution)
TypeSSRF (CWE-918), code execution, and more
Affectedall versions before 0.9.0 (range differs per flaw)
Fully fixed in0.9.0 and later (latest stable is 0.9.2)
Attack conditionsNo login / over the network (when Docker API server is exposed)

Who is at risk, and what is the damage

The targets are attackers who scan for Crawl4AI Docker API servers exposed to the internet and hit them without authentication. The classic dangerous setup is a server spun up quickly for AI development or data-collection testing that ends up reachable from outside.

Exploiting the fact that crawl target URLs are not validated, the attacker makes the server itself reach internal-network or cloud internal addresses. A prime target is the internal address a cloud VM uses to fetch its own configuration and credentials (cloud metadata, e.g. 169.254.169.254). Reaching it lets the attacker steal cloud access keys.

Once the cloud keys are taken, the damage does not stop at that one server. The attacker can use the keys to move into the whole cloud environment — exfiltrating or destroying stored data, hijacking other services, running up fraudulent charges — and can probe internal services on the network side. Crawl4AI is often embedded as an AI data-collection base, so the impact grows if it sits in a production pipeline. That is why the update and exposure review below are urgent.

One caveat: the risk is mainly in the "Docker API server" configuration exposed on a network. If you only call Crawl4AI as a library inside your own program, you are less likely to be directly affected. The starting point is confirming how you run Crawl4AI.

What is happening, technically

It is classified as CWE-918 (SSRF). The core is that endpoints such as /crawl and /llm fetch a given URL without sufficient validation. Even where there is a check to block access to internal addresses, an irregular notation like an "IPv6-mapped IPv4 address" can slip past it and reach internal services or cloud metadata, as reported.

The CVSS v3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N: over the network, low complexity, no privileges or user interaction, with impact spreading beyond the component and high confidentiality impact. The weight is on reading (theft) rather than direct modification or downtime — but since what gets stolen is cloud keys, the secondary damage can be severe.

0.8.7 fixed several related flaws at once

CVE-2026-56266 is not alone; it is one of a cluster of flaws found in Crawl4AI's Docker API server, all fixed in 0.8.7. The advisory covers file write, SSRF, authentication bypass, and script execution. Of particular note are a pre-authentication RCE (CVE-2026-53753) reported to allow code execution on the server without logging in. In short, 0.8.7 is not a single patch but an update that raises the overall safety of the Docker API server, and it should be applied without fail.

CVE-2026-56265 (CVSS 9.8): hard-coded JWT signing key in the Docker API server — fixed in 0.8.7

CVE-2026-56265 lives in the authentication mechanism of Crawl4AI's Docker API server. To verify users, the server issues tokens called JWTs. A JWT is a digital pass carrying a signature that says "this pass is genuine," and the key that checks whether that signature is valid is the linchpin of forgery protection. In Crawl4AI, the default value of this signing key was written as a fixed constant inside the public source code. NVD classifies it as CWE-798 (use of hard-coded credentials).

What happens when the key is public? A token's signature rests on the premise that "only someone who knows the key can produce a valid signature." If the key is readable by anyone, that premise collapses. The attacker can use the fixed signing key to create a fake token that says "I am the administrator" and attach a signature indistinguishable from the real thing. Because the server only checks whether the signature is valid, it accepts the forged token as a legitimate pass. No need to steal a password or brute-force anything. The severity is rated CVSS 9.8, reflecting that no privileges are required at all (PR:N, no authentication) and that it can be done over the network.

0.8.7 alone is not enough: what got fixed up to 0.9.0

The Docker API server problems did not end with CVE-2026-56266. Between 0.8.7 and 0.9.0, unauthenticated code execution and further SSRFs were fixed one after another. Here are the ones that decide which version to update to. The last one, CVE-2026-57573, still remains in 0.8.9, which is exactly why 0.9.0 or later is required to be safe.

CVE-2026-53753 (CVSS 9.8): unauthenticated code execution on the server (sandbox escape)

More severe than the lead SSRF, this is an unauthenticated remote code execution. Crawl4AI has a mechanism (_safe_eval_expression) to safely evaluate simple expressions used in extraction rules and the like. But its safety check only blocked "attributes starting with an underscore." Python's internal objects have dangerous attributes that do not start with an underscore, such as gi_frame, f_back, and f_builtins; chaining these slips past the check and runs arbitrary code (sandbox escape, CWE-94). The entry point is POST /crawl, and because JWT is disabled by default, it works without authentication. Fixed in 0.8.7 (advisory). If you expose the Docker API server, close it first.

CVE-2026-53755 (CVSS 8.6): SSRF via proxy settings — fixed in 0.8.9

The next is an SSRF. The Docker API server applied SSRF destination checks to the crawl-target URL but not to the proxy address, so an attacker can point a proxy at an internal IP and reach internal services or cloud metadata (CWE-918, NVD). This SSRF is fixed in 0.8.9 or later per NVD. But that is not enough: the next flaw, CVE-2026-57573, still remains in 0.8.9, so closing everything for sure requires 0.9.0 or later.

CVE-2026-57573 (CVSS 8.6): another unauthenticated SSRF hitting the streaming entry point — fixed in 0.9.0

What still remained in 0.8.9 is CVE-2026-57573. The Docker API server has a "streaming" entry point (/crawl/stream) that returns results in pieces. It fetched the URL without going through the destination check (validate_url_destination) used by the non-streaming path, so an unauthenticated attacker can make the server fetch internal, private, or link-local URLs and receive the body in the response (CWE-918). Severity is CVSS 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N). It affects every version before 0.9.0 and remains in 0.8.7 and 0.8.9; fixed in 0.9.0 (GHSA-wm69-2pc3-rmmf). Security firm IONIX reports it is "tracking ongoing exploitation attempts" against this flaw and urges an immediate update.

CVE-2026-57572 (CVSS 10.0): browser launch options abused for unauthenticated command execution — fixed in 0.9.0

Crawl4AI's Docker API server took the startup options for the browser (Chromium) it uses to fetch pages from a browser_config.extra_args field in the request. That field was not sufficiently validated, so an attacker who sends "launch another program" options such as --gpu-launcher or --renderer-cmd-prefix combined with --no-zygote makes Chromium execute the attacker's chosen command. The affected endpoints are /crawl, /crawl/stream, and /crawl/job, and because the Docker edition asks for no login by default, a single request leads to command execution on the server. NVD classifies it as CWE-88 (argument-delimiter handling) and CWE-94 (improper control of code generation). In 0.9.0 the boundary was redrawn to reject extra_args from untrusted requests (returning HTTP 400).

CVE-2026-57571 (CVSS 9.6): crafted saved filenames write outside the folder — fixed in 0.9.0

A flaw in how filenames are handled when saving files during a crawl. If an attacker plants a name containing "go up a level" sequences or an absolute path, files can be written outside the intended download folder. Because the written bytes can be attacker-controlled, it is described as potentially escalating to command execution. It is classified as CWE-22 (path traversal) and CWE-59 (link following). Exploiting it requires a prerequisite such as getting the crawler to visit an attacker-prepared page, but on success arbitrary content can be placed on the server (GHSA-2jq4-q6vv-4cp3).

Both of these are also rated top-tier Critical and are fixed in 0.9.0. They, too, point to 0.9.0 or later — and the latest 0.9.2 in production — as the answer.

Confirmed vs. still unknown

✓ Confirmed facts

  • CVE-2026-56266 is an unauthenticated SSRF that can reach internal and cloud metadata; fixed in 0.8.7 (NVD / Crawl4AI advisory)
  • 0.8.7 also fixed several related flaws, including unauthenticated code execution (CVE-2026-53753, CVSS 9.8)
  • A further unauthenticated SSRF (CVE-2026-57573) and unauthenticated code execution were later found and fixed together in 0.9.0; closing everything for sure needs 0.9.0 or later (latest is 0.9.2)
  • Security firm IONIX reports it is "tracking ongoing exploitation attempts" against CVE-2026-57573 (IONIX)

? Not yet confirmed

  • ?Real-world exploitation of CVE-2026-56266 itself, or a public PoC for it — not confirmed as of July 23, 2026
  • ?The CVEs (56266 / 53753 / 53755 / 57573) are not on CISA KEV (the US government list of vulnerabilities under active attack) as of July 23, 2026

What to do now

The top priority is to update Crawl4AI. If you run anything before 0.9.0, treat it as affected by one flaw or another, test or production — and apply it urgently if you run the Docker API server. Do not stop at an intermediate 0.8.7 or 0.8.9; go to 0.9.0 or later, which closes the whole cluster for sure. 0.8.7 closes the unauthenticated code execution (CVE-2026-53753) and SSRF (CVE-2026-56266), and 0.8.9 closes the proxy-based SSRF (CVE-2026-53755), but the streaming-path SSRF (CVE-2026-57573) remains until 0.9.0. In production, use the latest stable 0.9.2 to be safe.

If you cannot update right away, do not expose the Crawl4AI server directly to the internet — keep it behind the internal network or a VPN and restrict source addresses. If you run it in the cloud, reduce the blast radius of stolen credentials: require the token-based (latest) method for metadata access, and give the crawler the least privilege possible. To avoid missing flaws in OSS packages like Crawl4AI, keep a way to continuously check your OSS dependencies so you can move quickly on the next one.

Summary

Crawl4AI, a popular AI crawler, carries several serious flaws in every version before 0.9.0 that target its Docker API server: an SSRF that lets an unauthenticated attacker use the server as a springboard for internal probing (CVE-2026-56266 and others), unauthenticated command execution (CVE-2026-57572, CVSS 10.0), unauthenticated code execution (CVE-2026-53753, CVSS 9.8), a hard-coded authentication signing key (CVE-2026-56265, CVSS 9.8), and another SSRF on the streaming path (CVE-2026-57573) — potentially stealing access keys via cloud metadata. Because flaws remain that 0.8.7 and 0.8.9 do not fully close, closing everything for sure requires 0.9.0 or later, and in production the latest 0.9.2.

As of July 23, 2026, no widespread exploitation that would put these on CISA KEV is confirmed, though CVE-2026-57573, found later, has reported exploitation attempts. In AI development, data-collection tools are often spun up, exposed, and forgotten. Use this as a prompt to review the update and to know which servers are running and how exposed they are.

References

avatar-m-1

Makoto Horikawa

Backend Engineer / AWS / Django