GHSA-365w-hqf6-vxfg: Multiple Critical Vulnerabilities in Crawl4AI Docker API Server

The Crawl4AI Docker API server, running versions 0.8.6 and prior, contains multiple critical and high-severity security vulnerabilities. Crawl4AI is an open-source, LLM-friendly web crawler and scraper designed to facilitate content extraction for artificial intelligence applications. The Docker API server exposing this crawl engine to network consumers serves as the primary attack surface, handling external requests for scraping, screenshot generation, and dynamic JavaScript execution.

These vulnerabilities span multiple weakness categories, including improper path sanitization (CWE-22), missing authentication dependencies (CWE-306), use of hardcoded credentials (CWE-798), server-side request forgery (CWE-918), and improper code execution controls (CWE-94). An unauthenticated remote attacker can exploit these weaknesses to execute arbitrary code, manipulate files on the host file system, or pivot into private cloud infrastructure.

The vulnerabilities represent a complete breakdown of input sanitization and access control boundaries within the API wrapper. Because the Docker container often runs with elevated privileges on internal hosting networks, compromise of this component allows an attacker to gain a foothold inside private deployment environments. This technical analysis explores the root causes, code paths, exploitation vectors, and remediation strategies for these combined issues.

The root causes of these vulnerabilities lie in the omission of fundamental input validation and authentication checks across several critical API endpoints. In the case of the screenshot (/screenshot) and PDF (/pdf) generation routes, the application accepted optional user-defined file path parameters without applying sanitization routines. This lack of restriction allowed file-system path traversal sequences to escape the designated temporary directory.

For the Server-Side Request Forgery (SSRF) vulnerabilities, the application failed to validate destination IP addresses and hostnames before dispatching outbound requests. This allowed users to supply webhooks and target crawl targets pointing to loopback addresses, private networks, or metadata services. The validation routine was also vulnerable to evasion techniques such as IPv6-mapped IPv4 notation, which bypasses standard string-matching defenses by representing IPv4 addresses within IPv6 wrappers.

Additionally, the API server lacked structured access control boundaries. It failed to apply authentication dependencies to administrative routes, and fell back to a hardcoded JWT signing secret ('mysecret') when the token configuration was omitted. Dynamic code execution paths in the extraction strategies also suffered from unsafe eval and exec invocations, allowing attackers to execute arbitrary Python commands via manipulated dynamic schemas.

An inspection of the codebase prior to version 0.8.7 reveals how parameters were handled and how the patches remediated these flaws. In the vulnerable implementation of the path handling logic, raw user strings were passed to storage writers. The following comparison illustrates the transition from unsafe parameter consumption to structured Pydantic path validation:

# Vulnerable Path Consumption in server.py
@app.post("/screenshot")
async def take_screenshot(payload: ScreenshotPayload):
    # Unsanitized path accepted directly from client payload
    output_path = payload.output_path 
    await browser.screenshot(url=payload.url, path=output_path)

# Patched Path Validation in server.py (v0.8.7)
from pathlib import Path
from pydantic import BaseModel, field_validator
 
class ScreenshotPayload(BaseModel):
    url: str
    output_path: str
 
    @field_validator('output_path')
    @classmethod
    def validate_output_path(cls, v: str) -> str:
        # Ensure relative traversal sequences are blocked
        if '..' in v or v.startswith('/'):
            raise ValueError("Invalid output path structure")
        return v

To address the SSRF vulnerabilities, the developers introduced strict destination validation. The validation logic converts incoming URLs to normalized IP addresses and checks them against private subnets and metadata ranges, specifically resolving IPv6-mapped IPv4 variants. The following flow diagram demonstrates the validation sequence applied to inbound URLs:

Furthermore, the dynamic field computation logic in server.py and extraction_strategy.py was refactored to eliminate unsafe calls to eval. Commit 2fc39cbe89f3213ab2c0c3a04f25af795ee46047 restricted runtime interpretation by replacing arbitrary expression evaluation with structured AST (Abstract Syntax Tree) parsing and an explicit, safe attribute allowlist.

Exploitation of these vulnerabilities requires network access to the Crawl4AI Docker API server, which by default runs on port 8000. Because the administrative monitoring routes lacked authentication, an attacker could interact directly with endpoints such as /monitor/actions/cleanup or listen to sensitive events on the WebSocket /monitor/ws without providing any authentication credentials.

To execute an arbitrary file write attack, the attacker submits a POST request to /screenshot containing a relative path traversal sequence. The local file-writing mechanism processes this path and overwrites files on the container, such as the main server source code (/app/server.py). This path traversal vector achieves code modification and service disruption:

POST /screenshot HTTP/1.1
Host: local-crawl4ai-api:8000
Content-Type: application/json
 
{
  "url": "https://example.com",
  "output_path": "../../../../app/server.py"
}

For Server-Side Request Forgery, an attacker bypasses naive string filters by targeting internal resources using IPv6-mapped IPv4 addresses. A request sent to /crawl with the URL http://[::ffff:169.254.169.254]/latest/meta-data/ instructs the headless browser to retrieve data from the local cloud metadata endpoint. The crawler then returns this sensitive data to the remote attacker inside the standard HTTP response payload.

The cumulative security impact of these vulnerabilities is classified as critical, with a maximum CVSS v3.1 base score of 9.8. Successful exploitation of the unauthenticated endpoints allows complete compromise of the containerized application. An attacker can write arbitrary files to alter application logic, bypass JWT verification using the hardcoded default secret 'mysecret', and retrieve administrative information via the unsecured monitoring interface.

The presence of Server-Side Request Forgery (SSRF) represents a significant threat to cloud environments. If the Crawl4AI container is deployed within AWS, GCP, or Azure with access to the instance metadata service, an attacker can extract temporary IAM credentials, API tokens, and project metadata. This allows the attacker to escalate privileges and access adjacent resources inside the host cloud environment.

Additionally, the ability to run arbitrary JavaScript via /execute_js with disabled web security options allows attackers to perform cross-origin requests. Attackers can leverage the container's identity to query internal systems on the local Docker network, bypassing firewall protections and compromising other microservices that trust the container.

The primary remediation for these vulnerabilities is upgrading the Crawl4AI package to version 0.8.7 or higher. The update implements robust input sanitization, removes dynamic code evaluation paths, closes the authentication gaps on the monitoring endpoints, and introduces a dynamic secret generation mechanism for JWT authentication if no strong custom secret is configured.

If immediate patching is not possible, administrators must implement several compensatory controls to reduce the risk of exploitation. First, network exposure must be limited by binding the API server to localhost or restricting access to authorized IP addresses via network security groups. Second, the CRAWL4AI_API_TOKEN environment variable must be populated with a strong, complex token to enforce authentication across all API endpoints:

# Example of setting a strong API token and custom JWT secret
export CRAWL4AI_API_TOKEN="s3cur3_v3ry_str0ng_t0k3n_123"
export JWT_SECRET_KEY="a_very_long_and_secure_random_key_of_32_bytes_or_more"

Finally, dynamic JavaScript execution should be disabled unless strictly required. Ensure that the environment variable CRAWL4AI_EXECUTE_JS_ENABLED is set to false, and run the container with restricted security profiles to prevent arbitrary file modifications from affecting the host file system.