CVE-2026-57572: Critical Remote Code Execution in Crawl4AI

Affected versions and exposure conditions

The affected product is Crawl4AI, and the authoritative affected range provided in the NVD description is “prior to 0.9.0.” The fixed version is explicitly stated as “0.9.0.” If you are running any Crawl4AI release earlier than 0.9.0, you should consider that instance vulnerable unless you have independently verified that the vulnerable code path is removed or effectively isolated.

Because the bug sits in the Docker API server, exposure depends on how the service is deployed and who can reach it. The highest-risk cases are environments where the Crawl4AI API is internet-accessible, reachable from shared internal networks, exposed to untrusted tenants, or published behind weak reverse proxy rules. Since the API is described as unauthenticated by default, defenders should assume that any reachable instance is a viable target until proven otherwise.

Teams should also think beyond direct internet exposure. A vulnerable internal-only service can still be exploited after phishing, VPN compromise, SSRF, CI/CD compromise, or lateral movement from another container or host. If your threat model includes untrusted workloads on the same network segment, the absence of public exposure does not eliminate urgency.

Exploitation status, PoC status, and defender assumptions

At the time of writing, CISA KEV does not list CVE-2026-57572, and the research note indicates no formal confirmation of exploitation in the wild from that source. That is useful context, but it is not proof that exploitation has not happened. KEV is a lagging and selective dataset, not a comprehensive telemetry feed for all active attacks.

Likewise, the provided source material does not identify a primary-source public proof-of-concept repository. So the most accurate current statement is: no public PoC was identified in the provided references, and exploitation in the wild is not confirmed by CISA KEV. Defenders should still treat the issue as likely to become weaponized quickly because the attack does not require authentication and the vulnerable parameter is named directly in the public description.

When hard evidence is absent, the right operational assumption is conservative: if you have a reachable vulnerable instance, assume an attacker could develop or already possess a working exploit. That assumption is especially important for internet-facing services and for containers with mounted credentials, cloud metadata access, internal API reachability, or broad egress.

Root cause and attack chain

The root cause is unsafe handling of untrusted input in browser_config.extra_args. Crawl4AI’s Docker API server accepted attacker-controlled values and passed them into Chromium launch arguments. That creates an argument injection scenario in a process-launch context, which is exactly the sort of boundary where “just passing through options” becomes dangerous.

According to the NVD description, an attacker can inject Chromium switches that replace a child-process launch command and combine that with --no-zygote, causing Chromium to fork or exec an attacker-controlled command. The resulting execution occurs as the container runtime user. That detail matters operationally because privilege level inside the container will determine post-exploitation options, but even a non-root container user can often access application data, scrape tokens, and pivot to internal services.

Technical Notes

A simplified example of the risky pattern is an API accepting JSON like this:

{
  "url": "https://example.com",
  "browser_config": {
    "extra_args": [
      "--some-chromium-switch",
      "--another-switch"
    ]
  }
}

If those arguments are passed through to Chromium without strict allowlisting, an attacker may be able to supply switches that alter child process execution behavior. The exact malicious payload should be verified from upstream advisory and fix context rather than guessed from incomplete data. Defenders do not need a full exploit string to act; the presence of untrusted extra_args flowing into browser launch is sufficient to justify emergency patching.

What defenders should do next

First, inventory any Crawl4AI deployments and determine whether they are running a version prior to 0.9.0. If you cannot immediately determine version, treat the service as potentially vulnerable until verified. Then assess exposure: is the Docker API reachable from the internet, from broad internal ranges, or from other tenant workloads?

Second, patch and validate. After upgrading to 0.9.0, confirm that your containers are actually running the new image and that old instances are gone. Then perform log review for historical requests referencing browser_config.extra_args and inspect the container for suspicious processes or outbound connections. If you find evidence of likely exploitation, rotate credentials and secrets that were accessible to the container, because command execution frequently leads to token theft.

Additional Resources

For further reading, check out our articles on what is Stride and comparing the best secure web gateways for 2026.