Vulnerability-Lookup

GHSA-QG25-6GC4-48MG

Vulnerability from github – Published: 2026-10-08 16:36 – Updated: 2026-10-08 16:36

Summary

PraisonAI: DNS rebinding bypass in `web_crawl` SSRF protection allows internal response disclosure

Details

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 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

Attacker controls a hostname (e.g. rebind.lab) whose authoritative DNS rebinds.
Lookup #1 (the guard) → a public IP → _is_safe_crawl_url() returns true.
The backend re-resolves → the attacker's DNS now answers an internal/private IP (cloud metadata, loopback, internal service).
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

Burp Repeater tab PRAI-05-01-DNS-Rebind-Trigger → 127.0.0.1:18080:

POST /tool/web_crawl HTTP/1.1
Host: 127.0.0.1:18080
Content-Type: application/json

{"url":"http://rebind.lab:8081/secret"}

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.
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:

{"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.

01-DNS-Rebind-Burp-Readback

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.

02-DNS-Rebind-DNS-Log-And-Internal-Hit

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.

03-Redirect-Burp-Readback

Redirect chain runtime evidence

The controlled redirector returns 302 -> http://internal-canary:8081/secret, and the internal canary receives GET /secret, confirming that the server-side client followed the redirect into the internal network.

04-Redirect-Internal-Hit-Log

Reproduction assets

The attached archive contains the local Docker runtime used to reproduce the issue with controlled canary services only. It does not contain real secrets, real cloud metadata access, or third-party API keys.

PraisonAI-Runtime-Repro.zip

Impact

SSRF against internal/loopback/cloud-metadata endpoints with disclosure of internal HTTP responses (read-back) to the attacker. Bypasses the project's SSRF protection on every fetch backend.

Suggested remediation

Resolve the host once, reject all returned records that are private/loopback/link-local/ULA/CGNAT/metadata, then connect to that exact validated IP (pin it; send the original Host). Do not let the HTTP client / browser re-resolve.
Apply the same validation + IP pinning to every backend (httpx, urllib fallback, crawl4ai) and every redirect hop.
Disable automatic redirect following (or cap + re-validate each hop with pinning).
Treat IPv4-mapped IPv6, decimal/octal/hex IPs, and CGNAT/non-global ranges as unsafe.

Severity

8.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.6.77"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonaiagents"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.78"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61430"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T16:36:50Z",
    "nvd_published_at": "2026-07-15T17:16:52Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nPraisonAI\u0027s `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.\n\nThis is **SSRF with internal response disclosure (read-back)** \u2014 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).\n\n## Details\n\n### Affected component\n- Package: `praisonaiagents` (PraisonAI), version **4.6.63**.\n- File: `src/praisonai-agents/praisonaiagents/tools/web_crawl_tools.py`; tool `web_crawl` / `crawl_web` (part of the default bot tool set).\n\n### Vulnerable code / root cause\n\n**Code point 1 \u2014 check-time-only DNS validation, no IP pinning**\n\nPath:\n`src/praisonai-agents/praisonaiagents/tools/web_crawl_tools.py`\n\nFunction:\n`_is_safe_crawl_url`\n\nSnippet:\n```python\nfor info in socket.getaddrinfo(hostname, None):          # resolve at CHECK time\n    ip = ipaddress.ip_address(info[4][0])\n    if (ip.is_loopback or ip.is_private or ip.is_link_local\n            or ip.is_multicast or ip.is_unspecified):\n        return False\nreturn True\n```\nIssue: 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.\n\n**Code point 2 \u2014 guard runs, then the URL *string* is handed to the backend**\n\nFunction:\n`web_crawl`\n\nSnippet:\n```python\nfor u in raw_url_list:\n    if _is_safe_crawl_url(u):       # validate the URL string\n        url_list.append(u)\n...\nresults = _crawl_with_httpx(url_list)   # or _crawl_with_crawl4ai(url_list)\n```\nIssue: 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.\n\n**Code point 3 \u2014 `_crawl_with_httpx` backend re-resolves (redirect re-validation does not stop rebinding)**\n\nFunction:\n`_crawl_with_httpx`\n\nSnippet:\n```python\nwith httpx.Client(follow_redirects=False, timeout=30.0) as client:\n    for _ in range(max_redirects + 1):\n        if not _is_safe_crawl_url(current):   # re-resolves hostname (CHECK)\n            raise ValueError(\"Redirect target failed SSRF validation\")\n        response = client.get(current)        # resolves AGAIN at CONNECT\n```\nIssue: 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 \u2192 TOCTOU bypass. No IP pinning.\n\n**Code point 4 \u2014 urllib fallback (same function), no per-hop guard**\n\nSnippet:\n```python\nimport urllib.request\nwith urllib.request.urlopen(url, timeout=30) as response:   # re-resolves + auto-follows redirects\n    content = response.read().decode(\u0027utf-8\u0027, errors=\u0027ignore\u0027)\n```\nIssue: 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.)\n\n**Code point 5 \u2014 crawl4ai/Chromium backend (confirmed addendum)**\n\nThe crawl4ai backend (`_crawl_with_crawl4ai` \u2192 `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`.\n\n### Attack flow\n1. Attacker controls a hostname (e.g. `rebind.lab`) whose authoritative DNS rebinds.\n2. Lookup #1 (the guard) \u2192 a public IP \u2192 `_is_safe_crawl_url()` returns true.\n3. The backend re-resolves \u2192 the attacker\u0027s DNS now answers an internal/private IP (cloud metadata, loopback, internal service).\n4. The backend connects to the internal service and returns its body to the caller \u2192 internal data disclosure.\n\n### Why existing protection is bypassed\n- The guard validates the hostname, not a pinned IP; check and connect resolve independently \u2192 DNS rebinding (TOCTOU) defeats it on every backend.\n- 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.\n\n### Security boundary\nThe 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).\n\n## Proof of Concept\n\n### Environment\nReal 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\\`.\n\n### Steps to reproduce\n1. Burp Repeater tab `PRAI-05-01-DNS-Rebind-Trigger` \u2192 `127.0.0.1:18080`:\n```http\nPOST /tool/web_crawl HTTP/1.1\nHost: 127.0.0.1:18080\nContent-Type: application/json\n\n{\"url\":\"http://rebind.lab:8081/secret\"}\n```\n2. Send (`PRAI-05-02-DNS-Rebind-Secret-Readback` captures the response). If a send returns the \"blocked\" error, the rebinding DNS auto-resets (~3s) \u2014 resend.\n3. Redirect variant: `PRAI-05-03-Redirect-Trigger` / `PRAI-05-04-Redirect-Secret-Readback` send `{\"url\":\"http://redirector:8082/redirect-to-internal\"}`.\n\n### Expected result\nA safe SSRF guard refuses destinations that resolve to internal/private IPs regardless of DNS timing or redirects, and does not return internal content.\n\n### Actual result\nHTTP 200 with the internal body in the crawl result. Primary evidence is the `provider: \"httpx\"` backend returning the internal canary via DNS rebinding:\n```json\n{\"input_url\":\"http://rebind.lab:8081/secret\",\n \"result\":{\"content\":\"{ ... \\\"secret\\\": \\\"PRAISONAI_INTERNAL_SECRET_CANARY_7f3a91\\\", \\\"token\\\": \\\"FAKE_INTERNAL_TOKEN_DO_NOT_USE_7f3a91\\\" ... }\",\"provider\":\"httpx\"}}\n```\nThe redirect variant returns the same internal markers via a redirect chain (`provider: \"httpx\"`).\n\n### Screenshots\n\n**DNS rebinding read-back**\n\nThe attacker-controlled `rebind.lab` URL is accepted by `web_crawl`, and the PraisonAI response contains the internal canary response body.\n\n\u003cimg width=\"1543\" height=\"785\" alt=\"01-DNS-Rebind-Burp-Readback\" src=\"https://github.com/user-attachments/assets/e86e95dd-3d3a-4bef-b1c6-cb897234a212\" /\u003e\n\n**DNS rebinding runtime evidence**\n\nThe 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.\n\n\u003cimg width=\"1654\" height=\"828\" alt=\"02-DNS-Rebind-DNS-Log-And-Internal-Hit\" src=\"https://github.com/user-attachments/assets/f1d28046-de34-48f0-9bee-bbe26e598d5f\" /\u003e\n\n**Redirect-based SSRF read-back**\n\nThe 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`.\n\n\u003cimg width=\"1540\" height=\"772\" alt=\"03-Redirect-Burp-Readback\" src=\"https://github.com/user-attachments/assets/79eec159-4b9f-44be-a9eb-b15aba35ead8\" /\u003e\n\n**Redirect chain runtime evidence**\n\nThe controlled redirector returns `302 -\u003e http://internal-canary:8081/secret`, and the internal canary receives `GET /secret`, confirming that the server-side client followed the redirect into the internal network.\n\n\u003cimg width=\"1637\" height=\"894\" alt=\"04-Redirect-Internal-Hit-Log\" src=\"https://github.com/user-attachments/assets/1c503e30-9d01-4d32-8658-497f755a969e\" /\u003e\n\n### Reproduction assets\n\nThe attached archive contains the local Docker runtime used to reproduce the issue with controlled canary services only. It does not contain real secrets, real cloud metadata access, or third-party API keys.\n\n[PraisonAI-Runtime-Repro.zip](https://github.com/user-attachments/files/29142379/PraisonAI-Runtime-Repro.zip)\n\n## Impact\nSSRF against internal/loopback/cloud-metadata endpoints with **disclosure of internal HTTP responses** (read-back) to the attacker. Bypasses the project\u0027s SSRF protection on every fetch backend.\n\n## Suggested remediation\n1. Resolve the host once, reject all returned records that are private/loopback/link-local/ULA/CGNAT/metadata, then **connect to that exact validated IP** (pin it; send the original `Host`). Do not let the HTTP client / browser re-resolve.\n2. Apply the same validation + IP pinning to every backend (httpx, urllib fallback, crawl4ai) and every redirect hop.\n3. Disable automatic redirect following (or cap + re-validate each hop with pinning).\n4. Treat IPv4-mapped IPv6, decimal/octal/hex IPs, and CGNAT/non-global ranges as unsafe.",
  "id": "GHSA-qg25-6gc4-48mg",
  "modified": "2026-10-08T16:36:50Z",
  "published": "2026-10-08T16:36:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-qg25-6gc4-48mg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61430"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62169"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/praisonai-before-dns-rebinding-ssrf-via-web-crawl"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI: DNS rebinding bypass in `web_crawl` SSRF protection allows internal response disclosure"
}

CVE-2026-61430 (GCVE-0-2026-61430)

Vulnerability from cvelistv5 – Published: 2026-07-15 11:25 – Updated: 2026-07-15 12:17

Title

PraisonAI before 1.6.78 DNS Rebinding SSRF via web_crawl

Summary

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.

Severity

8.4 (High)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N

8.5 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-07-15 12:17 UTC

CWE

CWE-918 - Server-Side Request Forgery (SSRF)

Assigner

VulnCheck mitre root Scorecard

References

2 references

URL	Tags
https://github.com/MervinPraison/PraisonAI/securi…	vendor-advisory
https://www.vulncheck.com/advisories/praisonai-be…	third-party-advisory

Impacted products

1 product

Vendor	Product	Version
MervinPraison	PraisonAI	Affected: 0 , < 1.6.78 (semver) Unaffected: 1.6.78 (semver) cpe:2.3:a:praison:praisonai::::::::

Date Public

2026-06-25 00:00

Credits

dinhvaren

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-61430",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-15T12:17:04.943171Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-15T12:17:13.357Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-qg25-6gc4-48mg"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageURL": "pkg:pypi/praisonaiagents",
          "product": "PraisonAI",
          "vendor": "MervinPraison",
          "versions": [
            {
              "lessThan": "1.6.78",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "1.6.78",
              "versionType": "semver"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:praison:praisonai:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "1.6.78",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "dinhvaren"
        }
      ],
      "datePublic": "2026-06-25T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "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."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.4,
            "baseSeverity": "HIGH",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "LOW",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "LOW"
          },
          "format": "CVSS"
        },
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "LOW",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-918",
              "description": "Server-Side Request Forgery (SSRF)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-15T11:25:38.279Z",
        "orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
        "shortName": "VulnCheck"
      },
      "references": [
        {
          "name": "GitHub Security Advisory (GHSA-qg25-6gc4-48mg)",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-qg25-6gc4-48mg"
        },
        {
          "name": "VulnCheck Advisory: PraisonAI before 1.6.78 DNS Rebinding SSRF via web_crawl",
          "tags": [
            "third-party-advisory"
          ],
          "url": "https://www.vulncheck.com/advisories/praisonai-before-dns-rebinding-ssrf-via-web-crawl"
        }
      ],
      "title": "PraisonAI before 1.6.78 DNS Rebinding SSRF via web_crawl",
      "x_generator": {
        "engine": "vulncheck-endgame"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
    "assignerShortName": "VulnCheck",
    "cveId": "CVE-2026-61430",
    "datePublished": "2026-07-15T11:25:38.279Z",
    "dateReserved": "2026-07-09T14:05:21.470Z",
    "dateUpdated": "2026-07-15T12:17:13.357Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-QG25-6GC4-48MG

Summary

Details

Affected component

Vulnerable code / root cause

Attack flow

Why existing protection is bypassed

Security boundary

Proof of Concept

Environment

Steps to reproduce

Expected result

Actual result

Screenshots

Reproduction assets

Impact

Suggested remediation

CVE-2026-61430 (GCVE-0-2026-61430)

Tags

Sightings

Nomenclature

Related by attack behaviour