Unclecode
Monthly
Authenticated clients of the Crawl4AI Docker API server (0.9.0 through 0.9.4) can freeze the entire service, including the /health endpoint, by submitting a catastrophic-backtracking regular expression in a /crawl request body through RegexExtractionStrategy.custom, RegexChunking.patterns, or a schema field of type 'regex' in the JSON extraction strategies. Python's re engine does not release the GIL while matching, so a single crafted pattern combined with an attacker-influenced page blocks the event loop and the crawl deadline cannot interrupt it. Exploitation requires a valid API bearer token and a crawl target whose text triggers the backtracking; a public proof-of-concept request is published in the vendor advisory, no active exploitation has been reported, and the vendor fixed the issue in 0.9.5. The library imported directly is not exposed unless the host application itself feeds untrusted regexes into these strategies.
Server-side request forgery in Crawl4AI (unclecode) versions 0.7.0 through 0.9.3 lets unauthenticated, remote API clients force the crawler to fetch internal, private, and cloud-metadata URLs and hand back the parsed head data of those responses. The attack abuses the optional link_preview_config on /crawl requests: an attacker submits a page they control with include_external and include_patterns enabled, and the AsyncUrlSeeder component then follows links pointing at internal services or the cloud instance metadata endpoint. Exploitation requires the non-default link_preview_config feature to be active and the /crawl API to be network-reachable; the CVSS vector (PR:N, UI:N) indicates no authentication or user interaction is needed once those conditions hold. No public exploit code has been identified at time of analysis, and the issue is rated 9.2 under CVSS 4.0 (independent assessment: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N), making this a genuinely high-priority flaw for affected deployments.
Configuration-gate bypass in Crawl4AI 0.9.0 through 0.9.3 lets an authenticated but non-admin API client submit a laundered LLMConfig object through the server's configuration endpoint and read back environment-resolved secrets, including SECRET_KEY and provider API keys, which can then be used to forge admin JWTs. Exploitation requires Crawl4AI to be running in server/API mode with the /config/dump endpoint reachable and the attacker to already hold a provisioned non-admin API token (CVSS 4.0 base 8.6, vector PR:L), so pure library or embedded deployments are not affected; impact is highest where SECRET_KEY and provider keys are present in the server environment. Independent assessment flags this as a credible high-priority issue for hosted Crawl4AI deployments, with no public exploit identified at time of analysis and no CISA KEV listing.
Server-side request forgery in Crawl4AI before 0.9.3 lets an authenticated user of the crawling service force the server to fetch arbitrary internal URLs through the PDF scraping path. The PDFContentScrapingStrategy helper _get_pdf_path() re-downloads the target with the Python requests library without applying the crawler's egress validation, so an attacker-supplied URL that redirects to an internal address — or that relies on DNS rebinding — is fetched and its contents returned in the crawl result after PDF text extraction. CVSS 4.0 scoring is 8.3 (AV:N/AC:L/PR:L/UI:N, VC:H/SC:H), no CISA KEV listing or public exploit code was identified at time of analysis, and the fix is available in 0.9.3.
Denial of service in Crawl4AI before 0.9.3 lets untrusted clients exhaust disk, CPU and bandwidth on shared worker processes by choosing the PDF scraping strategy in POST crawl requests and pointing it at large remote PDFs that the server downloads without any size or page limits. The flaw is unauthenticated and remotely triggerable (CVSS 4.0 8.7, AV:N/AC:L/PR:N/UI:N) wherever the Crawl4AI HTTP/server mode is reachable by untrusted clients, while deployments that use Crawl4AI purely as an in-process library with operator-controlled URLs are not exposed. No CISA KEV listing, EPSS score or public exploit code was provided in the available intelligence, so active exploitation and exploit maturity are unconfirmed at time of analysis.
Arbitrary file write in crawl4ai before 0.9.3 allows remote attackers to plant attacker-controlled bytes anywhere the service account can write, by abusing the image_save_dir path accepted in a scrape configuration. The flaw sits in PDFContentScrapingStrategy, where _filter_untrusted_fields fails to validate untrusted configuration fields, so a crafted config body escapes the intended image output directory (CWE-22). Rated 8.7 with a network attack vector and no privileges or user interaction, but with no public exploit code or CISA KEV listing identified at the time of analysis.
Remote code execution in Crawl4AI's Docker API server (versions prior to 0.9.0) lets unauthenticated attackers run arbitrary commands as the container runtime user. The server passes request-supplied browser_config.extra_args directly into Chromium's launch arguments, enabling argument injection (CWE-88) of a malicious child-process launcher combined with --no-zygote. Because the Docker API is unauthenticated by default and CVSS is scored 10.0, a single crafted HTTP request achieves full container compromise; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Server-side request forgery in Crawl4AI's Docker API server (versions prior to 0.9.0) lets a remote unauthenticated client coerce the server into fetching attacker-chosen internal, private, or link-local URLs and streaming the response body back. The SSRF destination allowlist check was enforced on the non-streaming /crawl path but omitted from the streaming code path, so requests to POST /crawl/stream - or POST /crawl with crawler_config.stream=true - bypass validation entirely. No public exploit identified at time of analysis, but the fix is public in commit 60886d1 and the root cause (a guard applied to one path but not its sibling) is trivial to reproduce.
Arbitrary file write in Crawl4AI (the open-source LLM-friendly web crawler by unclecode) before version 0.9.0 lets a malicious website or download control where crawled files land on disk, and because the file contents are also attacker-controlled this escalates to remote code execution. Both the HTTP crawler path (trusting the response Content-Disposition filename) and the browser crawler path (trusting the download's suggested filename) are affected. CVSS is 9.6 (Critical); no public exploit is identified at time of analysis and it is not listed in CISA KEV, but a fix commit and GHSA advisory are published.
Server-side request forgery in Crawl4AI 0.8.7 through 0.9.5 lets unauthenticated, network-positioned attackers abuse the Docker API server's fetch_ssl_certificate=true path to make the service connect to internal hosts on TCP/443 and leak TLS certificate metadata or infer reachability. The vendor CVSS 4.0 score is 6.9, while the independent assessment is CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, reflecting low confidentiality impact only. No public exploit identified at time of analysis.
Blind server-side request forgery in Crawl4AI before 0.9.4 lets unauthenticated remote attackers bypass Docker egress controls via the RobotsParser.can_fetch robots.txt fetch path, using HTTP redirects or DNS rebinding to reach loopback, internal, and cloud-metadata addresses for service discovery. Rated CVSS 4.0 6.9 (Medium), exploitation requires the check_robots_txt behavior to be in effect when the service processes an attacker-influenced target URL, which makes the Docker service being reachable by untrusted callers a precondition. The SSRF is blind, so responses are not returned to the attacker, keeping confidentiality impact low; no public exploit code or confirmed active exploitation was identified at time of analysis.
A DOM-based cross-site scripting flaw in the Crawl4AI Playground UI (versions before 0.9.3) lets attacker-controlled crawled content — for example a malicious page title — be re-parsed as HTML inside the forceHighlightElement() routine, which writes textContent back into innerHTML. Because the Playground stores the operator's API token in sessionStorage, a successful payload can read that token and hand an attacker full control of the underlying Crawl4AI server. Exploitation requires the operator to load attacker-controlled page content in the Playground and trigger the highlight action; no public exploit code or CISA KEV entry is confirmed in the supplied intelligence, and the vendor has released a fix in 0.9.3.
Let me synthesize. CVE-2026-91942: crawl4ai before 0.9.3, DOM-based XSS in Docker Playground UI, innerHTML assignment of untrusted crawl results. Malicious PDFs with event-handler markup execute JS in Playground origin, steal API tokens from sessionStorage. CVSS 4.0 vector given: AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N — score 5.1. UI:A means user interaction active (user must open the PDF in the playground). Subsequent system impacts limited (SC:L/SI:L). PR:N unauthenticated. Wait — description says "steal API tokens from sessionStorage for authenticated API abuse" — the attacker themselves may be unauthenticated but the victim is an authenticated user. PR:N with UI:A. Let me construct fields. product_name: "Crawl4AI" (2 words? one token). Fine. prevalence: crawl4ai is a popular open-source LLM-friendly web crawler — medium? It's fairly widely used in AI/RAG pipelines. It's a Python library with ~40k GitHub stars. Deployment footprint: medium. Docker Playground UI is a specific deployment mode though — that reduces. I'd say "medium" with basis "popular open-source LLM crawler; Playground UI subset narrower". Hmm, but the specific vulnerable component (Docker Playground UI) is niche. But prevalence is about the product. crawl4ai is popular open-source library. Medium seems fair. assessed_cvss_vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N — scope changed because it impacts the Playground origin / API tokens (sessionStorage tokens, the script executes in the Playground origin). Actually the CVSS 4.0 vector shows SC:L/SI:L which implies subsequent system impacts → in 3.1 that maps to S:C with C:L/I:L. Hmm, but is scope change right? The vulnerable component is the Playground UI; the impacted component is... the API tokens / authenticated API. The XSS executes in the Playground origin — same origin. Stealing sessionStorage tokens then abusing the API — the API is arguably a different security authority. Given the CVSS 4.0 has subsequent-sys
Authenticated clients of the Crawl4AI Docker API server (0.9.0 through 0.9.4) can freeze the entire service, including the /health endpoint, by submitting a catastrophic-backtracking regular expression in a /crawl request body through RegexExtractionStrategy.custom, RegexChunking.patterns, or a schema field of type 'regex' in the JSON extraction strategies. Python's re engine does not release the GIL while matching, so a single crafted pattern combined with an attacker-influenced page blocks the event loop and the crawl deadline cannot interrupt it. Exploitation requires a valid API bearer token and a crawl target whose text triggers the backtracking; a public proof-of-concept request is published in the vendor advisory, no active exploitation has been reported, and the vendor fixed the issue in 0.9.5. The library imported directly is not exposed unless the host application itself feeds untrusted regexes into these strategies.
Server-side request forgery in Crawl4AI (unclecode) versions 0.7.0 through 0.9.3 lets unauthenticated, remote API clients force the crawler to fetch internal, private, and cloud-metadata URLs and hand back the parsed head data of those responses. The attack abuses the optional link_preview_config on /crawl requests: an attacker submits a page they control with include_external and include_patterns enabled, and the AsyncUrlSeeder component then follows links pointing at internal services or the cloud instance metadata endpoint. Exploitation requires the non-default link_preview_config feature to be active and the /crawl API to be network-reachable; the CVSS vector (PR:N, UI:N) indicates no authentication or user interaction is needed once those conditions hold. No public exploit code has been identified at time of analysis, and the issue is rated 9.2 under CVSS 4.0 (independent assessment: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N), making this a genuinely high-priority flaw for affected deployments.
Configuration-gate bypass in Crawl4AI 0.9.0 through 0.9.3 lets an authenticated but non-admin API client submit a laundered LLMConfig object through the server's configuration endpoint and read back environment-resolved secrets, including SECRET_KEY and provider API keys, which can then be used to forge admin JWTs. Exploitation requires Crawl4AI to be running in server/API mode with the /config/dump endpoint reachable and the attacker to already hold a provisioned non-admin API token (CVSS 4.0 base 8.6, vector PR:L), so pure library or embedded deployments are not affected; impact is highest where SECRET_KEY and provider keys are present in the server environment. Independent assessment flags this as a credible high-priority issue for hosted Crawl4AI deployments, with no public exploit identified at time of analysis and no CISA KEV listing.
Server-side request forgery in Crawl4AI before 0.9.3 lets an authenticated user of the crawling service force the server to fetch arbitrary internal URLs through the PDF scraping path. The PDFContentScrapingStrategy helper _get_pdf_path() re-downloads the target with the Python requests library without applying the crawler's egress validation, so an attacker-supplied URL that redirects to an internal address — or that relies on DNS rebinding — is fetched and its contents returned in the crawl result after PDF text extraction. CVSS 4.0 scoring is 8.3 (AV:N/AC:L/PR:L/UI:N, VC:H/SC:H), no CISA KEV listing or public exploit code was identified at time of analysis, and the fix is available in 0.9.3.
Denial of service in Crawl4AI before 0.9.3 lets untrusted clients exhaust disk, CPU and bandwidth on shared worker processes by choosing the PDF scraping strategy in POST crawl requests and pointing it at large remote PDFs that the server downloads without any size or page limits. The flaw is unauthenticated and remotely triggerable (CVSS 4.0 8.7, AV:N/AC:L/PR:N/UI:N) wherever the Crawl4AI HTTP/server mode is reachable by untrusted clients, while deployments that use Crawl4AI purely as an in-process library with operator-controlled URLs are not exposed. No CISA KEV listing, EPSS score or public exploit code was provided in the available intelligence, so active exploitation and exploit maturity are unconfirmed at time of analysis.
Arbitrary file write in crawl4ai before 0.9.3 allows remote attackers to plant attacker-controlled bytes anywhere the service account can write, by abusing the image_save_dir path accepted in a scrape configuration. The flaw sits in PDFContentScrapingStrategy, where _filter_untrusted_fields fails to validate untrusted configuration fields, so a crafted config body escapes the intended image output directory (CWE-22). Rated 8.7 with a network attack vector and no privileges or user interaction, but with no public exploit code or CISA KEV listing identified at the time of analysis.
Remote code execution in Crawl4AI's Docker API server (versions prior to 0.9.0) lets unauthenticated attackers run arbitrary commands as the container runtime user. The server passes request-supplied browser_config.extra_args directly into Chromium's launch arguments, enabling argument injection (CWE-88) of a malicious child-process launcher combined with --no-zygote. Because the Docker API is unauthenticated by default and CVSS is scored 10.0, a single crafted HTTP request achieves full container compromise; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Server-side request forgery in Crawl4AI's Docker API server (versions prior to 0.9.0) lets a remote unauthenticated client coerce the server into fetching attacker-chosen internal, private, or link-local URLs and streaming the response body back. The SSRF destination allowlist check was enforced on the non-streaming /crawl path but omitted from the streaming code path, so requests to POST /crawl/stream - or POST /crawl with crawler_config.stream=true - bypass validation entirely. No public exploit identified at time of analysis, but the fix is public in commit 60886d1 and the root cause (a guard applied to one path but not its sibling) is trivial to reproduce.
Arbitrary file write in Crawl4AI (the open-source LLM-friendly web crawler by unclecode) before version 0.9.0 lets a malicious website or download control where crawled files land on disk, and because the file contents are also attacker-controlled this escalates to remote code execution. Both the HTTP crawler path (trusting the response Content-Disposition filename) and the browser crawler path (trusting the download's suggested filename) are affected. CVSS is 9.6 (Critical); no public exploit is identified at time of analysis and it is not listed in CISA KEV, but a fix commit and GHSA advisory are published.
Server-side request forgery in Crawl4AI 0.8.7 through 0.9.5 lets unauthenticated, network-positioned attackers abuse the Docker API server's fetch_ssl_certificate=true path to make the service connect to internal hosts on TCP/443 and leak TLS certificate metadata or infer reachability. The vendor CVSS 4.0 score is 6.9, while the independent assessment is CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, reflecting low confidentiality impact only. No public exploit identified at time of analysis.
Blind server-side request forgery in Crawl4AI before 0.9.4 lets unauthenticated remote attackers bypass Docker egress controls via the RobotsParser.can_fetch robots.txt fetch path, using HTTP redirects or DNS rebinding to reach loopback, internal, and cloud-metadata addresses for service discovery. Rated CVSS 4.0 6.9 (Medium), exploitation requires the check_robots_txt behavior to be in effect when the service processes an attacker-influenced target URL, which makes the Docker service being reachable by untrusted callers a precondition. The SSRF is blind, so responses are not returned to the attacker, keeping confidentiality impact low; no public exploit code or confirmed active exploitation was identified at time of analysis.
A DOM-based cross-site scripting flaw in the Crawl4AI Playground UI (versions before 0.9.3) lets attacker-controlled crawled content — for example a malicious page title — be re-parsed as HTML inside the forceHighlightElement() routine, which writes textContent back into innerHTML. Because the Playground stores the operator's API token in sessionStorage, a successful payload can read that token and hand an attacker full control of the underlying Crawl4AI server. Exploitation requires the operator to load attacker-controlled page content in the Playground and trigger the highlight action; no public exploit code or CISA KEV entry is confirmed in the supplied intelligence, and the vendor has released a fix in 0.9.3.
Let me synthesize. CVE-2026-91942: crawl4ai before 0.9.3, DOM-based XSS in Docker Playground UI, innerHTML assignment of untrusted crawl results. Malicious PDFs with event-handler markup execute JS in Playground origin, steal API tokens from sessionStorage. CVSS 4.0 vector given: AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N — score 5.1. UI:A means user interaction active (user must open the PDF in the playground). Subsequent system impacts limited (SC:L/SI:L). PR:N unauthenticated. Wait — description says "steal API tokens from sessionStorage for authenticated API abuse" — the attacker themselves may be unauthenticated but the victim is an authenticated user. PR:N with UI:A. Let me construct fields. product_name: "Crawl4AI" (2 words? one token). Fine. prevalence: crawl4ai is a popular open-source LLM-friendly web crawler — medium? It's fairly widely used in AI/RAG pipelines. It's a Python library with ~40k GitHub stars. Deployment footprint: medium. Docker Playground UI is a specific deployment mode though — that reduces. I'd say "medium" with basis "popular open-source LLM crawler; Playground UI subset narrower". Hmm, but the specific vulnerable component (Docker Playground UI) is niche. But prevalence is about the product. crawl4ai is popular open-source library. Medium seems fair. assessed_cvss_vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N — scope changed because it impacts the Playground origin / API tokens (sessionStorage tokens, the script executes in the Playground origin). Actually the CVSS 4.0 vector shows SC:L/SI:L which implies subsequent system impacts → in 3.1 that maps to S:C with C:L/I:L. Hmm, but is scope change right? The vulnerable component is the Playground UI; the impacted component is... the API tokens / authenticated API. The XSS executes in the Playground origin — same origin. Stealing sessionStorage tokens then abusing the API — the API is arguably a different security authority. Given the CVSS 4.0 has subsequent-sys