Skip to content

← Public intelligence

PyPI package

crawl4ai

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Critical, CVSS 9.3PyPIAmendedPublished

    Crawl4AI: authentication bypass vulnerability due to a hardcoded default JWT signing key in the Docker API server

    CVE-2026-56265 · GHSA-8qrg-7j2f-rf2h

    Affected
    • PyPI crawl4ai < 0.8.7
    Fixed in
    0.8.7· Vendor fix available
    Issue
    Crawl4AI before 0.8.7 contains an authentication bypass vulnerability due to a hardcoded default JWT signing key in the Docker API server. Attackers who know the default key can forge valid authentication tokens for any user, bypassing authentication and gaining full access to protected functionality.

    Recommended action: Upgrade to 0.8.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  2. High, CVSS 8.6PyPIAmendedPublished

    Crawl4AI: Unauthenticated SSRF on the Docker server streaming crawl path (/crawl/stream)

    CVE-2026-57573 · GHSA-wm69-2pc3-rmmf

    Affected
    • PyPI crawl4ai <= 0.8.9
    Fixed in
    0.9.0· Vendor fix available
    Issue
    The Docker API server applied its SSRF destination check (validateurldestination) on the non-streaming /crawl path but not on the streaming path. handlestreamcrawlrequest passed seed URLs straight to the crawler with no destination validation. A remote, unauthenticated client could call POST /crawl/stream (or POST /crawl with crawlerconfig.stream=true, which short-circuits to the same handler) with a URL pointing at an internal, private, or link-local address; the server fetched it and streamed the response body back. The Docker API is unauthenticated by default. Affected paths POST /crawl/stream, and POST /crawl with crawlerconfig.stream=true (both route to handlestreamcrawlrequest, deploy/docker/api.py). Impact Unauthenticated read server-side request forgery: an attacker reads internal-only services and cloud-metadata endpoints (e.g. http://169.254.169.254/ for IAM credentials), with the response body streamed back. This is the same class and severity as the project's…

    Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  3. Critical, CVSS 10.0PyPIAmendedPublished

    Crawl4AI: Unauthenticated RCE via Chromium launch-argument injection in browser_config.extra_args

    CVE-2026-57572 · GHSA-r253-r9jw-qg44

    Affected
    • PyPI crawl4ai <= 0.8.9
    Fixed in
    0.9.0· Vendor fix available
    Issue
    The Docker API server accepted a request-supplied browserconfig.extraargs, which flowed into Chromium's launch arguments. An attacker could inject Chromium switches that replace a child-process launch command (--utility-cmd-prefix, --renderer-cmd-prefix, --gpu-launcher, --browser-subprocess-path) together with --no-zygote, causing Chromium to fork/exec an attacker-controlled command as the container's runtime user. The Docker API is unauthenticated by default, so a single request yields arbitrary command execution. The earlier extraargs SSRF patch (0.8.9) used a denylist scoped to proxy/DNS flags; a denylist of launch switches is inherently incomplete, and these command-execution switches were not covered. Affected paths /crawl, /crawl/stream, /crawl/job accepting a request browserconfig.extraargs. Impact Unauthenticated remote code execution as the container runtime user; full read/write of application data, mounted secrets, environment, and tokens, and out-of-band…

    Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  4. Critical, CVSS 9.6PyPIAmendedPublished

    Crawl4AI: Arbitrary file write (path traversal) in crawler downloads can lead to RCE

    CVE-2026-57571 · GHSA-2jq4-q6vv-4cp3

    Affected
    • PyPI crawl4ai <= 0.8.9
    Fixed in
    0.9.0· Vendor fix available
    Issue
    When the crawler saves a downloaded file, the destination filename was taken from attacker-influenced input and joined to the downloads directory with no confinement. A filename containing an absolute path (e.g. /etc/cron.d/evil) or ../ traversal escaped the downloads directory, giving an arbitrary file write with attacker-controlled contents. Because the written bytes are attacker-controlled, this escalates to remote code execution (overwriting a shell rc-file, ~/.ssh/authorizedkeys, a cron entry, or a Python module on the import path). Affected paths Two download sinks in crawl4ai/asynccrawlerstrategy.py: - HTTP crawler (AsyncHTTPCrawlerStrategy): the filename is parsed from the response Content-Disposition header by extractfilename() and written via aiofiles.open(filepath, 'wb'). Reachable directly via the SDK, and via the unauthenticated Docker /crawl endpoint when an HTTPCrawlerConfig is supplied. - Browser crawler (AsyncPlaywrightCrawlerStrategy): the download's…

    Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  5. High, CVSS 8.6PyPIAmendedPublished

    Crawl4AI: SSRF via proxy settings in the Docker server bypasses the crawl-URL SSRF check

    CVE-2026-53755 · GHSA-6qhc-x826-342c

    Affected
    • PyPI crawl4ai <= 0.8.8
    Fixed in
    0.8.9· Vendor fix available
    Issue
    The Docker API server applied its SSRF destination check to the crawl target URL only, not to the proxy address. An unauthenticated request could supply a proxy pointing at an internal IP and route the browser through it, reaching internal services and cloud-metadata endpoints, while using a perfectly valid crawl URL. The Docker API is unauthenticated by default. Affected paths /crawl, /crawl/stream, and /crawl/job accept a browserconfig (and crawlerconfig). The following all feed Chromium's egress and were unchecked: - browserconfig.proxyconfig.server - browserconfig.proxy (deprecated field) - crawlerconfig.proxyconfig.server - --proxy-server / --proxy-pac-url / --proxy-bypass-list / --host-resolver-rules flags in browserconfig.extraargs Attack An attacker sends /crawl with a benign, validation-passing URL but a proxyconfig.server pointing at an internal IP. Chromium routes all requests through that proxy. For plain-HTTP targets the proxy receives the full request and can…

    Recommended action: Upgrade to 0.8.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  6. Critical, CVSS 9.2PyPIAmendedPublished

    Crawl4AI: Arbitrary file write (symlink/TOCTOU) plus log and webhook-header injection in Docker server

    CVE-2026-56258 · GHSA-7cx2-g3h9-382p

    Affected
    • PyPI crawl4ai <= 0.8.7
    Fixed in
    0.8.8· Vendor fix available
    Issue
    Three backward-compatible hardening fixes in the Docker API server. The headline issue is an arbitrary file write via the screenshot/PDF outputpath. 1. Arbitrary file write via outputpath symlink / TOCTOU (primary) POST /screenshot and POST /pdf accept an outputpath constrained to ALLOWEDOUTPUTDIR by validateoutputpath. The 0.8.7 check was string-only: it did not resolve symlinks, so a symlinked path component inside the output directory could redirect the write outside the directory, and the final open() followed symlinks. On a deployment where the runtime user can write executable/cron locations this is an arbitrary-write to code-execution primitive. The API is unauthenticated by default. Fix: validateoutputpath now resolves the real path (symlinks) of the parent and re-checks containment, and the write uses ONOFOLLOW (writeoutputfile). outputpath remains supported. 2. CRLF log injection (CWE-117) User-controlled URLs/errors reflected into log lines could embed CR/LF and…

    Recommended action: Upgrade to 0.8.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  7. High, CVSS 8.8PyPIAmendedPublished

    Crawl4AI: LLM credential exfiltration in Docker server via request base_url and env: token resolution

    CVE-2026-56259 · GHSA-f989-c77f-r2cq

    Affected
    • PyPI crawl4ai <= 0.8.7
    Fixed in
    0.8.8· Vendor fix available
    Issue
    The Docker API server let a request control where LLM calls were sent and which environment variable an LLM token resolved from. Both could be abused to exfiltrate server-held secrets. The Docker API is unauthenticated by default. Vector 1 - attacker baseurl /md, /llm, and /llm/job accepted a baseurl in the request and used it as the LLM endpoint while still attaching the server's configured provider API key. An attacker set baseurl to a server they control and received the provider key (and any provider keys the server holds) in the inbound request. Vector 2 - arbitrary environment variable read via env: LLMConfig(apitoken="env:NAME") resolved NAME from the server environment with os.getenv. Because request bodies were deserialized into LLMConfig (via a crawler config / extraction strategy), an attacker could set apitoken="env:SECRETKEY" (or env:REDISPASSWORD, etc.) and, paired with an attacker baseurl, exfiltrate that secret. Reading the server's SECRETKEY enables forging…

    Recommended action: Upgrade to 0.8.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  8. High, CVSS 7.5PyPIAmendedPublished

    Crawl4AI: SSRF filter bypass in Docker server via IPv6 transition forms (NAT64 / 6to4 / unspecified / v4-mapped)

    CVE-2026-53754 · GHSA-4qqr-vv2q-cmr5

    Affected
    • PyPI crawl4ai <= 0.8.7
    Fixed in
    0.8.8· Vendor fix available
    Issue
    The Docker API server's SSRF protection (validatewebhookurl / validateurldestination in deploy/docker/utils.py) used an explicit IPv4/IPv6 CIDR blocklist that missed several address families. An attacker could reach internal services and cloud metadata endpoints (e.g. 169.254.169.254) despite the filter by encoding an internal IPv4 address inside an IPv6 transition form, or by using the IPv6 unspecified address. Because the Docker API is unauthenticated by default (jwtenabled: false), no credentials are required. Affected paths The blocklist was applied to crawl URLs (POST /crawl, /md, /html, /screenshot, /pdf, /executejs) and webhook URLs (/crawl/job, /llm/job). All shared the same incomplete check. Bypasses The following all resolve to (or route to) blocked internal addresses but were NOT caught: - IPv6 unspecified :: - NAT64 64:ff9b::a9fe:a9fe (embeds 169.254.169.254) - 6to4 2002:a9fe:a9fe:: (embeds 169.254.169.254) - IPv4-mapped ::ffff:169.254.169.254 - IPv4-compatible…

    Recommended action: Upgrade to 0.8.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  9. Critical, CVSS 9.2PyPIAmendedPublished

    Crawl4AI: Multiple Docker API Vulnerabilities - File Write, SSRF, Auth Bypass, XSS, JS Execution

    CVE-2026-56266 · GHSA-365w-hqf6-vxfg

    Affected
    • PyPI crawl4ai <= 0.8.6
    Fixed in
    0.8.7· Vendor fix available
    Issue
    Multiple security vulnerabilities in the Crawl4AI Docker API server affecting endpoints for crawling, markdown/LLM extraction, screenshots, PDFs, webhooks, monitoring, JavaScript execution, and configuration. Vulnerabilities 1. Arbitrary File Write via /screenshot and /pdf (CWE-22, CVSS 9.1) The outputpath parameter accepts arbitrary filesystem paths with no validation. An attacker can overwrite server files (DoS) or write to any appuser-writable location. Fix: Added validateoutputpath() restricting writes to CRAWL4AIOUTPUTDIR (/tmp/crawl4ai-outputs by default). Added Pydantic fieldvalidator rejecting .. traversal sequences. 2. SSRF via Webhook URL (CWE-918, CVSS 8.6) Webhook URLs in /crawl/job and /llm/job accept internal/private IPs with no validation, enabling Server-Side Request Forgery against cloud metadata endpoints (169.254.169.254), internal services, and Docker networks. Fix: Added validatewebhookurl() with blocklist for RFC 1918, loopback, link-local, cloud…

    Recommended action: Upgrade to 0.8.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  10. Critical, CVSS 9.8PyPIAmendedPublished

    Crawl4AI: AST Sandbox Escape via gi_frame.f_back Chain - Pre-Auth RCE in Docker API

    CVE-2026-53753 · GHSA-qxjp-w3pj-48m7

    Affected
    • PyPI crawl4ai <= 0.8.6
    Fixed in
    0.8.7· Vendor fix available
    Issue
    The safeevalexpression() function in the computed fields feature uses an AST validator that only blocks attributes starting with underscore. Python generator and frame object attributes (giframe, fback, fbuiltins) do NOT start with underscore, enabling a complete sandbox escape to achieve arbitrary code execution. The attack requires no authentication (JWT disabled by default) and is triggered via POST /crawl with a crafted extraction schema. Attack Vector An attacker sends a POST /crawl request with a JsonCssExtractionStrategy schema containing a malicious computed field expression that: 1. Creates a generator to access giframe 2. Walks the frame chain via fback 3. Reaches fbuiltins containing the real import 4. Imports os and executes arbitrary commands Impact Unauthenticated remote code execution inside the Docker container. An attacker can execute arbitrary system commands, read/write files, and exfiltrate secrets. Fix Details 1. Removed eval() from computed field…

    Recommended action: Upgrade to 0.8.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  11. Critical, CVSS 10.0PyPIAmendedPublished

    Crawl4AI is Vulnerable to Remote Code Execution in Docker API via Hooks Parameter

    CVE-2026-26216 · GHSA-5882-5rx9-xgxp

    Affected
    • PyPI crawl4ai < 0.8.0
    Fixed in
    0.8.0· Vendor fix available
    Issue
    A critical remote code execution vulnerability exists in the Crawl4AI Docker API deployment. The /crawl endpoint accepts a hooks parameter containing Python code that is executed using exec(). The import builtin was included in the allowed builtins, allowing attackers to import arbitrary modules and execute system commands. Attack Vector: Impact An unauthenticated attacker can: - Execute arbitrary system commands - Read/write files on the server - Exfiltrate sensitive data (environment variables, API keys) - Pivot to internal network services - Completely compromise the server Mitigation 1. Upgrade to v0.8.0 (recommended) 2. If unable to upgrade immediately: - Disable the Docker API - Block /crawl endpoint at network level - Add authentication to the API Fix Details 1. Removed import from allowedbuiltins in hookmanager.py 2. Hooks disabled by default (CRAWL4AIHOOKSENABLED=false) 3. Users must explicitly opt-in to enable hooks Credits Discovered by Neo by ProjectDiscovery…

    Recommended action: Upgrade to 0.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  12. Critical, CVSS 9.2PyPIAmendedPublished

    Crawl4AI Has Local File Inclusion in Docker API via file:// URLs

    CVE-2026-26217 · GHSA-vx9w-5cx4-9796

    Affected
    • PyPI crawl4ai < 0.8.0
    Fixed in
    0.8.0· Vendor fix available
    Issue
    A local file inclusion vulnerability exists in the Crawl4AI Docker API. The /executejs, /screenshot, /pdf, and /html endpoints accept file:// URLs, allowing attackers to read arbitrary files from the server filesystem. Attack Vector: Impact An unauthenticated attacker can: - Read sensitive files (/etc/passwd, /etc/shadow, application configs) - Access environment variables via /proc/self/environ - Discover internal application structure - Potentially read credentials and API keys Workarounds 1. Disable the Docker API 2. Add authentication to the API 3. Use network-level filtering

    Recommended action: Upgrade to 0.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →