Crawl4ai
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.
Arbitrary file write in Crawl4AI's Docker API server (versions before 0.8.7) lets remote unauthenticated attackers overwrite any file writable by the service account by abusing the unvalidated output_path parameter on the /screenshot and /pdf endpoints. Reported by VulnCheck and disclosed in GitHub advisory GHSA-365w-hqf6-vxfg, the flaw enables path traversal or absolute-path writes that corrupt server files and cause denial of service. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the network-reachable, no-privileges attack surface makes it a straightforward target once a Crawl4AI Docker server is exposed.
Credential exfiltration in Crawl4AI's Docker API server (all versions before 0.8.8) lets remote unauthenticated attackers steal secrets from the host. By abusing the exposed /md, /llm, and /llm/job endpoints, an attacker supplies a malicious base_url to redirect outbound LLM API calls and sets api_token to the special form env:VARIABLE_NAME, causing the server to resolve and leak arbitrary environment variables - including provider API keys and the JWT SECRET_KEY, which in turn enables full authentication bypass. No public exploit identified at time of analysis, but the flaw is trivially exploitable and reported by VulnCheck with an assigned CVSS 4.0 score of 8.8.
Server-side request forgery in Crawl4AI's Docker API server (versions before 0.8.7) allows remote unauthenticated attackers to coerce the server into making arbitrary internal requests. The /crawl/job and /llm/job endpoints accept caller-supplied webhook URLs without validating the destination, so an attacker can target private IP ranges, Docker network internals, or the cloud metadata endpoint (169.254.169.254) to reach otherwise unreachable services and harvest credentials. CVSS 4.0 rates it 9.2 (critical); no public exploit identified at time of analysis, and it is not listed in CISA KEV.
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.
Arbitrary JavaScript execution in Crawl4AI's Docker API server (versions before 0.8.7) lets remote attackers submit code to the /execute_js endpoint, which runs it inside the server's Chromium browser context launched with --disable-web-security. Because the browser's same-origin and CORS protections are disabled, attacker-controlled JavaScript can pivot into server-side request forgery against internal services and metadata endpoints. No public exploit has been identified at time of analysis, and the CVSS 4.0 base score is 9.2 (critical), though the vector's high attack complexity and present attack requirements indicate exploitation is not fully trivial.
Arbitrary file write in Crawl4AI Docker API server before 0.8.8 lets unauthenticated remote attackers escape the ALLOWED_OUTPUT_DIR via symlinks and a TOCTOU race on the output_path parameter of the /screenshot and /pdf endpoints, potentially escalating to code execution where the runtime user can write to executable or cron paths. No public exploit identified at time of analysis, but the API is unauthenticated by default and the GHSA confirms the issue was found in an internal security audit.
Server-side request forgery in Crawl4AI before 0.8.7 allows unauthenticated remote attackers to coerce the server into fetching arbitrary internal URLs via the /crawl, /crawl/stream, /md, and /llm endpoints. The product's internal-address blocklist can be bypassed using IPv6-mapped IPv4 notation (e.g., ::ffff:169.254.169.254), exposing cloud metadata services and internal infrastructure. No public exploit identified at time of analysis, but the GHSA advisory and a VulnCheck write-up document the flaw in detail.
Authentication bypass in Crawl4AI Docker API server (versions prior to 0.8.7) allows remote unauthenticated attackers to forge valid JWT tokens because the signing key defaults to the hardcoded value 'mysecret' present in the public source code. Anyone aware of the default secret can mint tokens for arbitrary users and obtain full access to protected crawling, extraction, JavaScript execution, and configuration endpoints. No public exploit identified at time of analysis, but the underlying weakness is trivially reproducible from the upstream repository.
Arbitrary local file disclosure in Crawl4AI's Docker API (versions before 0.8.0) lets unauthenticated remote attackers read any file on the server by supplying file:// URLs to the /execute_js, /screenshot, /pdf, and /html endpoints. Because the API validates no scheme, an attacker can exfiltrate /etc/passwd, /etc/shadow, application config, and process environment via /proc/self/environ - directly exposing credentials and API keys. Publicly documented in GitHub advisory GHSA-vx9w-5cx4-9796 with a working request example; no public exploit identified as active exploitation, and EPSS is low (0.06%, 19th percentile).
Remote code execution in Crawl4AI Docker API before 0.8.0 via hooks parameter. The /crawl endpoint accepts Python code in hooks that executes on the server. EPSS 0.28%.
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
Authentication bypass in the Crawl4AI Docker API server before 0.8.7 exposes all monitor router endpoints - including the destructive /monitor/actions/cleanup action - to unauthenticated remote attackers due to missing token dependency injection on the monitor router. Any attacker with network access to the Docker API port can invoke cleanup operations and manipulate monitoring state, causing service disruption without credentials. No active exploitation (CISA KEV) or public POC has been identified at time of analysis; the CVSS 4.0 vector of AV:N/AC:L/AT:N/PR:N/UI:N confirms trivial remote unauthenticated access with no special conditions required.
Stored XSS in Crawl4AI's monitor dashboard (versions before 0.8.7) enables an unauthenticated remote attacker to inject persistent malicious markup by submitting a crafted crawl URL or triggering a crafted error message; the payload executes in any operator's browser that subsequently views the dashboard. This flaw is one of six vulnerabilities disclosed together in GHSA-365w-hqf6-vxfg, and its impact is materially amplified in unpatched deployments by a co-disclosed authentication bypass (CWE-306) that left all monitor endpoints, including the dashboard, accessible without credentials. No public exploit code or CISA KEV listing has been identified at time of analysis.
Crawl4AI <=0.4.247 is vulnerable to SSRF in /crawl4ai/async_dispatcher.py. Rated critical severity (CVSS 9.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
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.
Arbitrary file write in Crawl4AI's Docker API server (versions before 0.8.7) lets remote unauthenticated attackers overwrite any file writable by the service account by abusing the unvalidated output_path parameter on the /screenshot and /pdf endpoints. Reported by VulnCheck and disclosed in GitHub advisory GHSA-365w-hqf6-vxfg, the flaw enables path traversal or absolute-path writes that corrupt server files and cause denial of service. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the network-reachable, no-privileges attack surface makes it a straightforward target once a Crawl4AI Docker server is exposed.
Credential exfiltration in Crawl4AI's Docker API server (all versions before 0.8.8) lets remote unauthenticated attackers steal secrets from the host. By abusing the exposed /md, /llm, and /llm/job endpoints, an attacker supplies a malicious base_url to redirect outbound LLM API calls and sets api_token to the special form env:VARIABLE_NAME, causing the server to resolve and leak arbitrary environment variables - including provider API keys and the JWT SECRET_KEY, which in turn enables full authentication bypass. No public exploit identified at time of analysis, but the flaw is trivially exploitable and reported by VulnCheck with an assigned CVSS 4.0 score of 8.8.
Server-side request forgery in Crawl4AI's Docker API server (versions before 0.8.7) allows remote unauthenticated attackers to coerce the server into making arbitrary internal requests. The /crawl/job and /llm/job endpoints accept caller-supplied webhook URLs without validating the destination, so an attacker can target private IP ranges, Docker network internals, or the cloud metadata endpoint (169.254.169.254) to reach otherwise unreachable services and harvest credentials. CVSS 4.0 rates it 9.2 (critical); no public exploit identified at time of analysis, and it is not listed in CISA KEV.
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.
Arbitrary JavaScript execution in Crawl4AI's Docker API server (versions before 0.8.7) lets remote attackers submit code to the /execute_js endpoint, which runs it inside the server's Chromium browser context launched with --disable-web-security. Because the browser's same-origin and CORS protections are disabled, attacker-controlled JavaScript can pivot into server-side request forgery against internal services and metadata endpoints. No public exploit has been identified at time of analysis, and the CVSS 4.0 base score is 9.2 (critical), though the vector's high attack complexity and present attack requirements indicate exploitation is not fully trivial.
Arbitrary file write in Crawl4AI Docker API server before 0.8.8 lets unauthenticated remote attackers escape the ALLOWED_OUTPUT_DIR via symlinks and a TOCTOU race on the output_path parameter of the /screenshot and /pdf endpoints, potentially escalating to code execution where the runtime user can write to executable or cron paths. No public exploit identified at time of analysis, but the API is unauthenticated by default and the GHSA confirms the issue was found in an internal security audit.
Server-side request forgery in Crawl4AI before 0.8.7 allows unauthenticated remote attackers to coerce the server into fetching arbitrary internal URLs via the /crawl, /crawl/stream, /md, and /llm endpoints. The product's internal-address blocklist can be bypassed using IPv6-mapped IPv4 notation (e.g., ::ffff:169.254.169.254), exposing cloud metadata services and internal infrastructure. No public exploit identified at time of analysis, but the GHSA advisory and a VulnCheck write-up document the flaw in detail.
Authentication bypass in Crawl4AI Docker API server (versions prior to 0.8.7) allows remote unauthenticated attackers to forge valid JWT tokens because the signing key defaults to the hardcoded value 'mysecret' present in the public source code. Anyone aware of the default secret can mint tokens for arbitrary users and obtain full access to protected crawling, extraction, JavaScript execution, and configuration endpoints. No public exploit identified at time of analysis, but the underlying weakness is trivially reproducible from the upstream repository.
Arbitrary local file disclosure in Crawl4AI's Docker API (versions before 0.8.0) lets unauthenticated remote attackers read any file on the server by supplying file:// URLs to the /execute_js, /screenshot, /pdf, and /html endpoints. Because the API validates no scheme, an attacker can exfiltrate /etc/passwd, /etc/shadow, application config, and process environment via /proc/self/environ - directly exposing credentials and API keys. Publicly documented in GitHub advisory GHSA-vx9w-5cx4-9796 with a working request example; no public exploit identified as active exploitation, and EPSS is low (0.06%, 19th percentile).
Remote code execution in Crawl4AI Docker API before 0.8.0 via hooks parameter. The /crawl endpoint accepts Python code in hooks that executes on the server. EPSS 0.28%.
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
Authentication bypass in the Crawl4AI Docker API server before 0.8.7 exposes all monitor router endpoints - including the destructive /monitor/actions/cleanup action - to unauthenticated remote attackers due to missing token dependency injection on the monitor router. Any attacker with network access to the Docker API port can invoke cleanup operations and manipulate monitoring state, causing service disruption without credentials. No active exploitation (CISA KEV) or public POC has been identified at time of analysis; the CVSS 4.0 vector of AV:N/AC:L/AT:N/PR:N/UI:N confirms trivial remote unauthenticated access with no special conditions required.
Stored XSS in Crawl4AI's monitor dashboard (versions before 0.8.7) enables an unauthenticated remote attacker to inject persistent malicious markup by submitting a crafted crawl URL or triggering a crafted error message; the payload executes in any operator's browser that subsequently views the dashboard. This flaw is one of six vulnerabilities disclosed together in GHSA-365w-hqf6-vxfg, and its impact is materially amplified in unpatched deployments by a co-disclosed authentication bypass (CWE-306) that left all monitor endpoints, including the dashboard, accessible without credentials. No public exploit code or CISA KEV listing has been identified at time of analysis.
Crawl4AI <=0.4.247 is vulnerable to SSRF in /crawl4ai/async_dispatcher.py. Rated critical severity (CVSS 9.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.