CVE-2026-119119 in Crawl4AIinfo

Summary

by MITRE • 10/29/2026

Crawl4AI before 0.9.5 contains a denial of service vulnerability in the Docker API server where _clamp_untrusted() fails to cap the delay_before_return_html, mean_delay, and max_range fields of untrusted CrawlerRunConfig bodies. Unauthenticated attackers can send huge values to /crawl or /crawl/stream to hold browser pages or stall the rate limiter, exhausting the page pool and blocking other crawls.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 10/29/2026

The vulnerability identified in versions of Crawl4AI prior to 0.9.5 represents a critical denial of service flaw rooted in insufficient input validation within the Docker API server component. The core technical deficiency lies in the _clamp_untrusted() function, which is designed to sanitize and restrict values from untrusted sources but fails to enforce upper bounds on specific configuration fields including delay_before_return_html, mean_delay, and max_range when processing CrawlerRunConfig bodies submitted by users. This oversight allows an attacker to inject excessively large numerical values into these parameters without triggering any validation errors or automatic capping mechanisms that would normally prevent resource exhaustion scenarios.

From a technical perspective, the exploitation of this vulnerability involves sending crafted HTTP requests to either the /crawl or /crawl/stream endpoints with untrusted CrawlerRunConfig payloads containing abnormally high delay and range values. When the system processes these configurations, it attempts to allocate resources based on the specified parameters without applying necessary constraints. The failure to cap the mean_delay and max_range fields effectively allows an attacker to dictate how long browser instances remain open or active during crawling operations. This manipulation directly impacts the internal page pool mechanism, which is responsible for managing available browser contexts for concurrent tasks.

The operational impact of this vulnerability is severe as it enables unauthenticated attackers to exhaust system resources through a simple remote request. By setting extremely high values for delay parameters, an attacker can force the crawler to hold onto browser pages or stall its internal rate limiting logic indefinitely. This behavior leads to the depletion of available page slots in the pool, effectively blocking legitimate crawling operations from executing. The result is a complete denial of service where other users or processes are unable to utilize the Crawl4AI infrastructure because all resources are monopolized by the malicious requests exploiting this configuration flaw.

This vulnerability aligns with CWE-20 Improper Input Validation and CWE-770 Allocation of Resources Without Limits or Throttling, as it involves accepting untrusted input without enforcing limits on resource consumption. In terms of attack classification under MITRE ATT&CK, this behavior corresponds to T1496 Resource Hijacking where an attacker uses compromised resources for their own purposes, specifically causing a denial of service by exhausting the page pool and stalling operational processes. The lack of authentication requirement further exacerbates the risk as any external actor can trigger this condition without prior access credentials.

Mitigation strategies must focus on enforcing strict input validation at the API layer to ensure that all configuration parameters are bounded within acceptable limits before they influence system behavior. Updating Crawl4AI to version 0.9.5 or later is the primary remediation step as it addresses these specific clamping failures in the _clamp_untrusted() function. Additionally, implementing rate limiting and resource quotas at the network level can provide an additional layer of defense against such exhaustion attacks by capping the number of concurrent requests a single source can make regardless of the configuration values submitted within those requests.

Responsible

VulnCheck

Reservation

10/29/2026

Disclosure

10/29/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!