CVE-2026-61430

PraisonAI before 1.6.78 contains a server-side request forgery vulnerability in the web_crawl tool that validates hostnames at check time but re-resolves them at connection time without IP pinning. Attackers can use DNS rebinding to bypass SSRF protection and retrieve internal HTTP response bodies from private or loopback services.

PraisonAI before 1.6.78 contains a server-side request forgery vulnerability in the web_crawl tool that validates hostnames at check time but re-resolves them at connection time without IP pinning. Attackers can use DNS rebinding to bypass SSRF protection and retrieve internal HTTP response bodies from private or loopback services.

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-qg25-6gc4-48mg. This link is maintained to preserve external references.

Original Description

PraisonAI before 1.6.78 contains a server-side request forgery vulnerability in the web_crawl tool that validates hostnames at check time but re-resolves them at connection time without IP pinning. Attackers can use DNS rebinding to bypass SSRF protection and retrieve internal HTTP response bodies from private or loopback services.

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:

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:

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:

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:

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…

PraisonAI before 1.6.78 contains a server-side request forgery vulnerability in the web_crawl tool that validates hostnames at check time but re-resolves them at connection time without IP pinning. Attackers can use DNS rebinding to bypass SSRF protection and retrieve internal HTTP response bodies from private or loopback services.

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-qg25-6gc4-48mg. This link is maintained to preserve external references.

Original Description

PraisonAI before 1.6.78 contains a server-side request forgery vulnerability in the web_crawl tool that validates hostnames at check time but re-resolves them at connection time without IP pinning. Attackers can use DNS rebinding to bypass SSRF protection and retrieve internal HTTP response bodies from private or loopback services.

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:

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:

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:

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:

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…

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:

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:

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:

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:

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…