GHSA-qg25-6gc4-48mg PraisonAI: DNS rebinding bypass in `web_crawl` SSRF protection allows internal response disclosure

• PyPI praisonaiagents: < 1.6.78 → fixed in 1.6.78

Summary PraisonAI's `web_crawl` agent tool performs a server-side HTTP fetch of an agent/attacker-influenced URL. SSRF is meant to be prevented by `_is_safe_crawl_url()`, which resolves the hostname and rejects private/loopback/link-local IPs at validation time. The validated value is the URL *string* (not a pinned IP); the fetch backend then re-resolves the hostname at connection time. Because validation and connection perform two independent DNS resolutions, a DNS-rebinding domain that returns a public IP during validation and an internal IP during the fetch fully bypasses the guard, and the internal HTTP response body is returned to the caller. This is SSRF with internal response disclosure (read-back) — not blind SSRF. Runtime-confirmed against PraisonAI 4.6.63; the crawl response returned the controlled internal markers `PRAISONAI_INTERNAL_SECRET_CANARY_7f3a91` / `FAKE_INTERNAL_TOKEN_DO_NOT_USE_7f3a91`. Severity High. Reachable by any actor who can influence the URL an agent crawls (e.g. a chat/bot/agent surface). Details Affected component • Package: `praisonaiagents` (PraisonAI), version 4.6.63. • File: `src/praisonai-agents/praisonaiagents/tools/web_crawl_tools.py`; tool `web_crawl` / `crawl_web` (part of the default bot tool set). Vulnerable code / root cause Code point 1 — check-time-only DNS validation, no IP pinning Path: `src/praisonai-agents/praisonaiagents/tools/web_crawl_tools.py` Function: `_is_safe_crawl_url` Snippet: ```python for info in socket.getaddrinfo(hostname, None): # resolve at CHECK time ip = ipaddress.ip_address(info[4][0]) if (ip.is_loopback or ip.is_private or ip.is_link_local or ip.is_multicast or ip.is_unspecified): return False return True ``` Issue: the guard validates the hostname by resolving it once at check time. It does not pin the resolved IP and does not return/forward that IP to the HTTP client. Any later resolution can differ. **Code point 2 — guard runs, then the URL *string* is handed to the backend Function: `web_crawl` Snippet: ```python for u in raw_url_list: if _is_safe_crawl_url(u): # validate the URL string url_list.append(u) ... results = _crawl_with_httpx(url_list) # or _crawl_with_crawl4ai(url_list) ``` Issue: attacker-controlled input (`urls`) is validated as a string; the backend then fetches that string and re-resolves DNS independently of the guard. There is no shared, pinned IP between check and fetch. Code point 3 — `_crawl_with_httpx` backend re-resolves (redirect re-validation does not stop rebinding) Function: `_crawl_with_httpx` Snippet: ```python with httpx.Client(follow_redirects=False, timeout=30.0) as client: for _ in range(max_redirects + 1): if not _is_safe_crawl_url(current): # re-resolves hostname (CHECK) raise ValueError("Redirect target failed SSRF validation") response = client.get(current) # resolves AGAIN at CONNECT ``` Issue: even with per-hop redirect re-validation, `_is_safe_crawl_url(current)` and `client.get(current)` are two separate DNS resolutions of the same hostname. A rebinding domain answers public to the check and internal to the connect → TOCTOU bypass. No IP pinning. Code point 4 — urllib fallback (same function), no per-hop guard Snippet: ```python import urllib.request with urllib.request.urlopen(url, timeout=30) as response: # re-resolves + auto-follows redirects content = response.read().decode('utf-8', errors='ignore') ``` Issue: when `httpx` is not installed, this fallback inside `_crawl_with_httpx` fetches the URL and auto-follows redirects with no per-hop/per-connect validation. (Results from this function are labelled `"provider": "httpx"` regardless of which path runs.) Code point 5 — crawl4ai/Chromium backend (confirmed addendum)** The crawl4ai backend (`_crawl_with_crawl4ai` → `crawler.arun(url=url)`, headless Chromium) is also runtime-confirmed affected (browser re-resolves DNS / follows redirects with no per-connect guard). To keep this report focused on the `web_crawl` SSRF guard, the backend-specific evidence is in `SSRF-04_Crawl4AI_SSRF_Backend_Addendum.md`. Attack flow 1. Attacker controls a hostname (e.g. `rebind.lab`) whose authoritative DNS rebinds. 2. Lookup #1 (the guard) → a public IP → `_is_safe_crawl_url()` returns true. 3. The backend re-resolves → the attacker's DNS now answers an internal/private IP (cloud metadata, loopback, internal service). 4. The backend connects to the internal service and returns its body to the caller → internal data disclosure. Why existing protection is bypassed • The guard validates the hostname, not a pinned IP; check and connect resolve independently → DNS rebinding (TOCTOU) defeats it on every backend. • Redirect re-validation (httpx path) re-checks the *hostname* but still re-resolves at connect, so it does not stop rebinding; the urllib fallback and crawl4ai backends have no per-hop guard at all. Security boundary The server-side fetch reaches internal/loopback/metadata services not exposed to the attacker and returns their content (CVSS Scope: Changed). Reachable wherever an agent can be induced to crawl an attacker-supplied URL (PR:L). An unauthenticated single-request path to `web_crawl` read-back was not found in 4.6.63 (so PR:N / Critical is not claimed). Proof of Concept Environment Real PraisonAI 4.6.63 in a local Docker runtime; a controlled internal canary service (Docker-internal only, not published) returns synthetic markers; a controlled DNS responder implements rebinding for `rebind.lab`. No public host / real metadata / real secret. Runnable assets: `PraisonAI-Runtime-Repro\runtime-files\`. Steps to reproduce 1. Burp Repeater tab `PRAI-05-01-DNS-Rebind-Trigger` → `127.0.0.1:18080`: ```http POST /tool/web_crawl HTTP/1.1 Host: 127.0.0.1:18080 Content-Type: application/json {"url":"http://rebind.lab:8081/secret"} ``` 2. Send (`PRAI-05-02-DNS-Rebind-Secret-Readback` captures the response). If a send returns the "blocked" error, the rebinding DNS auto-resets (~3s) — resend. 3. Redirect variant: `PRAI-05-03-Redirect-Trigger` / `PRAI-05-04-Redirect-Secret-Readback` send `{"url":"http://redirector:8082/redirect-to-internal"}`. Expected result A safe SSRF guard refuses destinations that resolve to internal/private IPs regardless of DNS timing or redirects, and does not return internal content. Actual result HTTP 200 with the internal body in the crawl result. Primary evidence is the `provider: "httpx"` backend returning the internal canary via DNS rebinding: ```json {"input_url":"http://rebind.lab:8081/secret", "result":{"content":"{ ... \"secret\": \"PRAISONAI_INTERNAL_SECRET_CANARY_7f3a91\", \"token\": \"FAKE_INTERNAL_TOKEN_DO_NOT_USE_7f3a91\" ... }","provider":"httpx"}} ``` The redirect variant returns the same internal markers via a redirect chain (`provider: "httpx"`). Screenshots DNS rebinding read-back The attacker-controlled `rebind.lab` URL is accepted by `web_crawl`, and the PraisonAI response contains the internal canary response body. DNS rebinding runtime evidence The runtime log shows `rebind.lab` first resolving to an allowed/public IP during validation (`guard-pass`), then resolving to an internal Docker IP during the actual fetch (`fetch-hit`). The internal canary receives `GET /secret` from the PraisonAI container. Redirect-based SSRF read-back The attacker-controlled redirector URL is accepted by `web_crawl`. PraisonAI follows the redirect and returns the internal canary response body containing `PRAISONAI_INTERNAL_SECRET_CANARY_7f3a91`. <img width="1540" heig…