### Summary The Docker API server applied its SSRF destination check to the crawl target URL only, not to the proxy address. An unauthenticated request could supply a proxy pointing at an internal IP and route the browser through it, reaching internal services and cloud-metadata endpoints, while using a perfectly valid crawl URL. The Docker API is unauthenticated by default. ### Affected paths `/crawl`, `/crawl/stream`, and `/crawl/job` accept a `browser_config` (and `crawler_config`). The following all feed Chromium's egress and were unchecked: - `browser_config.proxy_config.server` - `browser_config.proxy` (deprecated field) - `crawler_config.proxy_config.server` - `--proxy-server` / `--proxy-pac-url` / `--proxy-bypass-list` / `--host-resolver-rules` flags in `browser_config.extra_args` ### Attack An attacker sends `/crawl` with a benign, validation-passing URL but a `proxy_config.server` pointing at an internal IP. Chromium routes all requests through that proxy. For plain-HTTP targets the proxy receives the full request and can return any content, which is then returned verbatim in the crawl result (`results[0].html` / `cleaned_html` / `markdown`). In a real deployment the proxy would be an attacker-controlled server pointing at cloud metadata (e.g. AWS IMDSv1 at 169.254.169.254) to retrieve IAM credential tokens. ### Impact Unauthenticated server-side request forgery to internal services and cloud-metadata endpoints, with the response returned to the attacker. ### Fix Every proxy destination is validated with the same global-routability check used for crawl URLs (reject any resolved address that is not `is_global`, including IPv6 transition forms) before the browser is constructed; proxy/DNS-redirecting flags are stripped from `extra_args`. A legitimate public proxy still works. Honors `CRAWL4AI_ALLOW_INTERNAL_URLS`. ### Workarounds - Upgrade to the patched version (0.8.9). - Enable authentication (`CRAWL4AI_API_TOKEN`). - Restrict the container's outbound network access (egress firewall / no metadata route). ### Credits Geo ([geo-chen](https://github.com/geo-chen)) - reported the proxy_config.server SSRF with a clear PoC.
### Summary The Docker API server applied its SSRF destination check to the crawl target URL only, not to the proxy address. An unauthenticated request could supply a proxy pointing at an internal IP and route the browser through it, reaching internal services and cloud-metadata endpoints, while using a perfectly valid crawl URL. The Docker API is unauthenticated by default. ### Affected paths `/crawl`, `/crawl/stream`, and `/crawl/job` accept a `browser_config` (and `crawler_config`). The following all feed Chromium's egress and were unchecked: - `browser_config.proxy_config.server` - `browser_config.proxy` (deprecated field) - `crawler_config.proxy_config.server` - `--proxy-server` / `--proxy-pac-url` / `--proxy-bypass-list` / `--host-resolver-rules` flags in `browser_config.extra_args` ### Attack An attacker sends `/crawl` with a benign, validation-passing URL but a `proxy_config.server` pointing at an internal IP. Chromium routes all requests through that proxy. For plain-HTTP targets the proxy receives the full request and can return any content, which is then returned verbatim in the crawl result (`results[0].html` / `cleaned_html` / `markdown`). In a real deployment the proxy would be an attacker-controlled server pointing at cloud metadata (e.g. AWS IMDSv1 at 169.254.169.254) to retrieve IAM credential tokens. ### Impact Unauthenticated server-side request forgery to internal services and cloud-metadata endpoints, with the response returned to the attacker. ### Fix Every proxy destination is validated with the same global-routability check used for crawl URLs (reject any resolved address that is not `is_global`, including IPv6 transition forms) before the browser is constructed; proxy/DNS-redirecting flags are stripped from `extra_args`. A legitimate public proxy still works. Honors `CRAWL4AI_ALLOW_INTERNAL_URLS`. ### Workarounds - Upgrade to the patched version (0.8.9). - Enable authentication (`CRAWL4AI_API_TOKEN`). - Restrict the container's outbound network access (egress firewall / no metadata route). ### Credits Geo ([geo-chen](https://github.com/geo-chen)) - reported the proxy_config.server SSRF with a clear PoC.
Update crawl4ai to 0.8.9 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanCrawl4AI: SSRF via proxy settings in the Docker server bypasses the crawl-URL SSRF check affects crawl4ai (pip). Severity is high. ### Summary The Docker API server applied its SSRF destination check to the crawl target URL only, not to the proxy address. An unauthenticated request could supply a proxy pointing at an internal IP and route the browser through it, reaching internal services and cloud-metadata endpoints, while using a perfectly valid crawl URL. The Docker API is unauthenticated by default. ### Affected paths `/crawl`, `/crawl/stream`, and `/crawl/job` accept a `browser_config` (and `crawler_config`). The following all feed Chromium's egress and were unchecked: - `browser_config.proxy_config.server` - `browser_config.proxy` (deprecated field) - `crawler_config.proxy_config.server` - `--proxy-server` / `--proxy-pac-url` / `--proxy-bypass-list` / `--host-resolver-rules` flags in `browser_config.extra_args` ### Attack An attacker sends `/crawl` with a benign, validation-passing URL but a `proxy_config.server` pointing at an internal IP. Chromium routes all requests through that proxy. For plain-HTTP targets the proxy receives the full request and can return any content, which is then returned verbatim in the crawl result (`results[0].html` / `cleaned_html` / `markdown`). In a real deployment the proxy would be an attacker-controlled server pointing at cloud metadata (e.g. AWS IMDSv1 at 169.254.169.254) to retrieve IAM credential tokens. ### Impact Unauthenticated server-side request forgery to internal services and cloud-metadata endpoints, with the response returned to the attacker. ### Fix Every proxy destination is validated with the same global-routability check used for crawl URLs (reject any resolved address that is not `is_global`, including IPv6 transition forms) before the browser is constructed; proxy/DNS-redirecting flags are stripped from `extra_args`. A legitimate public proxy still works. Honors `CRAWL4AI_ALLOW_INTERNAL_URLS`. ### Workarounds - Upgrade to the patched version (0.8.9). - Enable authentication (`CRAWL4AI_API_TOKEN`). - Restrict the container's outbound network access (egress firewall / no metadata route). ### Credits Geo ([geo-chen](https://github.com/geo-chen)) - reported the proxy_config.server SSRF with a clear PoC.
AI coding agents often install or upgrade packages automatically in pip. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| crawl4aipip | <=0.8.8 | 0.8.9 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate crawl4ai to 0.8.9 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanCrawl4AI: SSRF via proxy settings in the Docker server bypasses the crawl-URL SSRF check affects crawl4ai (pip). Severity is high. ### Summary The Docker API server applied its SSRF destination check to the crawl target URL only, not to the proxy address. An unauthenticated request could supply a proxy pointing at an internal IP and route the browser through it, reaching internal services and cloud-metadata endpoints, while using a perfectly valid crawl URL. The Docker API is unauthenticated by default. ### Affected paths `/crawl`, `/crawl/stream`, and `/crawl/job` accept a `browser_config` (and `crawler_config`). The following all feed Chromium's egress and were unchecked: - `browser_config.proxy_config.server` - `browser_config.proxy` (deprecated field) - `crawler_config.proxy_config.server` - `--proxy-server` / `--proxy-pac-url` / `--proxy-bypass-list` / `--host-resolver-rules` flags in `browser_config.extra_args` ### Attack An attacker sends `/crawl` with a benign, validation-passing URL but a `proxy_config.server` pointing at an internal IP. Chromium routes all requests through that proxy. For plain-HTTP targets the proxy receives the full request and can return any content, which is then returned verbatim in the crawl result (`results[0].html` / `cleaned_html` / `markdown`). In a real deployment the proxy would be an attacker-controlled server pointing at cloud metadata (e.g. AWS IMDSv1 at 169.254.169.254) to retrieve IAM credential tokens. ### Impact Unauthenticated server-side request forgery to internal services and cloud-metadata endpoints, with the response returned to the attacker. ### Fix Every proxy destination is validated with the same global-routability check used for crawl URLs (reject any resolved address that is not `is_global`, including IPv6 transition forms) before the browser is constructed; proxy/DNS-redirecting flags are stripped from `extra_args`. A legitimate public proxy still works. Honors `CRAWL4AI_ALLOW_INTERNAL_URLS`. ### Workarounds - Upgrade to the patched version (0.8.9). - Enable authentication (`CRAWL4AI_API_TOKEN`). - Restrict the container's outbound network access (egress firewall / no metadata route). ### Credits Geo ([geo-chen](https://github.com/geo-chen)) - reported the proxy_config.server SSRF with a clear PoC.
AI coding agents often install or upgrade packages automatically in pip. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| crawl4aipip | <=0.8.8 | 0.8.9 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard