| Package | Affected versions | Patched versions |
|---|---|---|
| crawl4ai | < 0.8.8 | 0.8.8 |
| crawl4ai | < 0.8.8 | 0.8.8 |
Three backward-compatible hardening fixes in the Docker API server. The headline issue is an arbitrary file write via the screenshot/PDF output_path.
POST /screenshot and POST /pdf accept an output_path constrained to ALLOWED_OUTPUT_DIR by validate_output_path. 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: validate_output_path now resolves the real path (symlinks) of the parent and re-checks containment, and the write uses O_NOFOLLOW (write_output_file). output_path remains supported.
User-controlled URLs/errors reflected into log lines could embed CR/LF and forge additional log entries. Fix: a logging filter strips CR/LF/control characters from all records.
User-supplied webhook headers were sent verbatim, allowing CRLF and hop-by-hop / sensitive header injection on the outbound webhook request. Fix: webhook headers are validated (name pattern, no control characters, deny Host/Content-Length/Transfer-Encoding/Authorization/Cookie/...), with early request-time rejection.
Arbitrary file write (potential code execution) for #1; log forging for #2; request smuggling / header injection on outbound webhooks for #3.
CRAWL4AI_API_TOKEN).Internal security audit (Crawl4AI maintainers).
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free