Fixes are not backported to earlier lines. The 0.9.3 advisories listed below are not patched in any 0.8.x release; if you run 0.8.x, upgrade.

We take security vulnerabilities seriously. If you discover a security issue, please report it responsibly.

DO NOT open a public GitHub issue for security vulnerabilities.

Instead, please report via one of these methods:

1. GitHub Security Advisories (Preferred)

   • Go to Security Advisories
   • Click "New draft security advisory"
   • Fill in the details

2. Email

   • Send details to: unclecode@crawl4ai.com (CC: nasrin@crawl4ai.com and aravind@crawl4ai.com)
   • Use subject: [SECURITY] Brief description
   • Include:
     • Description of the vulnerability
     • Steps to reproduce
     • Potential impact
     • Any suggested fixes

• Acknowledgment: Within 48 hours
• Initial Assessment: Within 7 days
• Resolution Timeline: Depends on severity
  • Critical: 24-72 hours
  • High: 7 days
  • Medium: 30 days
  • Low: 90 days

• We follow responsible disclosure practices
• We will coordinate with you on disclosure timing
• Credit will be given to reporters (unless anonymity is requested)
• We may request CVE assignment for significant vulnerabilities

If you're running the Crawl4AI Docker API in production:

1. Enable Authentication

   # config.yml
   security:
     enabled: true
     jwt_enabled: true

   # Set a strong secret key
   export SECRET_KEY="your-secure-random-key-here"

2. Hooks are Declarative (v0.9.0+)

   • Request-supplied hook code is no longer accepted; only the fixed action set in GET /hooks/info
   • On 0.8.x, hooks are disabled by default; set CRAWL4AI_HOOKS_ENABLED=true only if you trust all API users

3. Network Security

   • Run behind a reverse proxy (nginx, traefik)
   • Use HTTPS in production
   • Restrict access to trusted IPs if possible

4. Container Security

   • Run as non-root user (default in our container)
   • Use read-only filesystem where possible
   • Limit container resources

When using Crawl4AI as a Python library:

1. Validate URLs before crawling untrusted input
2. Sanitize extracted content before using in other systems
3. Be cautious with hooks - they execute arbitrary code

All issues below are fixed in the version named. Advisories with a GHSA id are published under Security Advisories. Full detail for every release is in CHANGELOG.md; reporter credits are in SECURITY-CREDITS.md.

Secure-by-default rework of the Docker API server. The pip library is unchanged. See deploy/docker/MIGRATION.md.

• Library egress proxy: crawl4ai/egress_policy.py routes the library's own HTTP clients (URL seeder, robots.txt) through the Docker server's pinning proxy, so they get the same resolve-and-pin rule as the browser
• Link preview caps: LinkPreviewConfig max_links (100), concurrency (10), and timeout (10 s) clamped for untrusted bodies
• Nested typed objects gated: {"type": "dict"} wrappers are re-checked against UNTRUSTED_ALLOWED_TYPES

• PDF egress policy: PDF downloads validate every redirect hop and the peer IP actually read, so the Docker SSRF policy also covers the out-of-browser requests path
• PDF resource caps: max_pdf_bytes (100 MiB) and max_pdf_pages (2000), not raisable from an untrusted request body
• PDF image-write fields filtered from untrusted bodies; extract_images forced off
• Egress proxy upstream chaining: the pinning egress proxy honours HTTP_PROXY / HTTPS_PROXY and refuses non-http proxy schemes
• Per-crawl wall clock: Docker config ships limits.wall_clock_s of 300 seconds

• Authentication on by default: loopback bind unless CRAWL4AI_API_TOKEN is set; Authorization: Bearer <token> required on every request except GET /health
• Request trust boundary: crawl request bodies carry scalar, declarative options only; browser internals and code fields are rejected with HTTP 400; unknown fields dropped; timeouts, viewport and scroll counts clamped
• Declarative hooks: hooks.code removed; fixed action set (block_resources, add_cookies, set_headers, scroll_to_bottom, wait_for_timeout)
• extra_args rejected over the network, closing the Chromium launch-arg injection class
• Artifact ids instead of output_path: /screenshot and /pdf return an artifact_id; fetch via authenticated GET /artifacts/{id} with TTL and quota
• Download path confinement: basename + realpath + O_NOFOLLOW
• SSRF validation on every crawl path, including /crawl/stream; internal targets need CRAWL4AI_ALLOW_INTERNAL_URLS=true
• Hardened JWT (tokens from older versions are invalid; re-mint via POST /token); admin scope for /monitor/actions/* and /monitor/stats/reset
• CORS deny by default (security.cors_allow_origins); strict security headers
• TLS verification on; escape hatch CRAWL4AI_ALLOW_INSECURE_TLS=true
• Redis password-protected and loopback-only; port no longer published
• Bounded job queue: body size, per-crawl wall clock, queue size and per-principal concurrency capped
• Generic 5xx responses with a correlation id; webhook headers validated (HTTP 422 on malformed or hop-by-hop headers)
• LLM provider by name only: base_url removed; providers constrained by config.llm.allowed_providers

• Global-routability SSRF check on crawl targets, webhook URLs and proxy destinations, evaluated on IPv6 transition forms
• /execute_js disabled by default (CRAWL4AI_EXECUTE_JS_ENABLED)
• No default JWT secret; weak secrets rejected
• Monitor routes authenticated; monitor dashboard output escaped
• eval() removed from computed fields and /config/dump
• Protected env vars cannot be resolved through the LLMConfig env: token form
• CRLF-safe logging

• Deserialization Allowlist: Only known-safe types can be instantiated via API config

• URL Scheme Validation: Blocks file://, javascript:, data: URLs on API
• Hooks Disabled by Default: Opt-in via CRAWL4AI_HOOKS_ENABLED=true (replaced by declarative hooks in 0.9.0)
• Restricted Hook Builtins: No __import__, eval, exec, open
• JWT Authentication: Optional (on by default since 0.9.0)
• Rate Limiting: Configurable request limits
• Security Headers: X-Frame-Options, CSP, HSTS when enabled

We thank the security researchers who responsibly disclosed the issues above. The full list, with the vulnerability each person reported and the release that fixed it, is maintained in SECURITY-CREDITS.md.

Last updated: September 2026