GHSA-Q9PW-VMHH-384G

Vulnerability from github – Published: 2026-05-06 22:08 – Updated: 2026-05-12 13:33
VLAI?
Summary
PraisonAI has an SSRF bypass
Details

Summary

The URL checking logic in PraisonAI has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.

Details

The current PraisonAI project uses _validate_url to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks.

QQ20260424-151256-24-1

However, there are indeed differences in parsing between urlparse and the library that actually sends the request. Currently, almost all application scenarios in this project involve first using _validate_url for URL validation, and then using _get_session().get to send the request.

QQ20260424-151437-24-2

In reality, its underlying mechanism is requests.get.

QQ20260424-151645-24-3

The core issue: urlparse() and requests disagree on which host a URL like http://127.0.0.1:6666\@1.1.1.1 points to:

  • urlparse() treats \ as a regular character and @ as the userinfo-host delimiter, so it extracts hostname as 1.1.1.1 (public)
  • requests treats \ as a path character, connecting to 127.0.0.1 (internal)

Below is a test code I wrote following the code.

import sys
from pathlib import Path
from pprint import pprint

sys.path.insert(0, str(Path(r"D:/BaiduNetdiskDownload/PraisonAI-main/PraisonAI-main/src/praisonai-agents")))

from praisonaiagents.tools import spider_tools

# url = "http://127.0.0.1:6666\@1.1.1.1"
url = "http://127.0.0.1:6666"

result = spider_tools.scrape_page(url)

if isinstance(result, dict) and "error" in result:
    print("scrape failed:", result["error"])
else:
    pprint(result)

When an attacker uses http://127.0.0.1:6666/, the existing detection logic can detect that this is an internal network address and block it.

QQ20260424-152007-24-4

However, when an attacker uses http://127.0.0.1:6666\@1.1.1.1, the detection logic resolves the host to 1.1.1.1, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to http://127.0.0.1:6666, bypassing the detection and achieving an SSRF attack.

QQ20260424-152123-24-5

PoC

http://127.0.0.1:6666\@1.1.1.1

Impact

SSRF

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.6.31"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonaiagents"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.32"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44335"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T22:08:11Z",
    "nvd_published_at": "2026-05-08T14:16:46Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nThe URL checking logic in PraisonAI has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.\n\n### Details\nThe current PraisonAI project uses _validate_url to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks.\n\n\u003cimg width=\"1290\" height=\"1145\" alt=\"QQ20260424-151256-24-1\" src=\"https://github.com/user-attachments/assets/d5f16b74-5ad2-444f-8600-b05f78a4b769\" /\u003e\n\nHowever, there are indeed differences in parsing between urlparse and the library that actually sends the request. Currently, almost all application scenarios in this project involve first using _validate_url for URL validation, and then using _get_session().get to send the request.\n\n\u003cimg width=\"1143\" height=\"740\" alt=\"QQ20260424-151437-24-2\" src=\"https://github.com/user-attachments/assets/b1bf6ec2-d32a-4dac-b814-da819e8d3c83\" /\u003e\n\nIn reality, its underlying mechanism is requests.get.\n\n\u003cimg width=\"1042\" height=\"576\" alt=\"QQ20260424-151645-24-3\" src=\"https://github.com/user-attachments/assets/e17352c3-4205-44d6-ab6e-75566480215b\" /\u003e\n\nThe core issue:\u00a0`urlparse()`\u00a0and\u00a0`requests`\u00a0disagree on which host a URL like\u00a0`http://127.0.0.1:6666\\@1.1.1.1`\u00a0points to:\n\n- `urlparse()`\u00a0treats\u00a0`\\`\u00a0as a regular character and\u00a0`@`\u00a0as the userinfo-host delimiter, so it extracts hostname as\u00a0`1.1.1.1`\u00a0(public)\n- `requests`\u00a0treats\u00a0`\\`\u00a0as a path character, connecting to\u00a0`127.0.0.1`\u00a0(internal)\n\nBelow is a test code I wrote following the code.\n\n```\nimport sys\nfrom pathlib import Path\nfrom pprint import pprint\n\nsys.path.insert(0, str(Path(r\"D:/BaiduNetdiskDownload/PraisonAI-main/PraisonAI-main/src/praisonai-agents\")))\n\nfrom praisonaiagents.tools import spider_tools\n\n# url = \"http://127.0.0.1:6666\\@1.1.1.1\"\nurl = \"http://127.0.0.1:6666\"\n\nresult = spider_tools.scrape_page(url)\n\nif isinstance(result, dict) and \"error\" in result:\n    print(\"scrape failed:\", result[\"error\"])\nelse:\n    pprint(result)\n```\nWhen an attacker uses `http://127.0.0.1:6666/`, the existing detection logic can detect that this is an internal network address and block it.\n\n\u003cimg width=\"1068\" height=\"128\" alt=\"QQ20260424-152007-24-4\" src=\"https://github.com/user-attachments/assets/294bff10-2af6-4960-bf69-dbf3340b1e9b\" /\u003e\n\nHowever, when an attacker uses `http://127.0.0.1:6666\\@1.1.1.1`, the detection logic resolves the host to `1.1.1.1`, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to `http://127.0.0.1:6666`, bypassing the detection and achieving an SSRF attack.\n\n\u003cimg width=\"2089\" height=\"324\" alt=\"QQ20260424-152123-24-5\" src=\"https://github.com/user-attachments/assets/4421ce42-e47b-48de-a97a-56ce56a2bbc9\" /\u003e\n\n### PoC\n```\nhttp://127.0.0.1:6666\\@1.1.1.1\n```\n\n### Impact\nSSRF",
  "id": "GHSA-q9pw-vmhh-384g",
  "modified": "2026-05-12T13:33:12Z",
  "published": "2026-05-06T22:08:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-q9pw-vmhh-384g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44335"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "PraisonAI has an SSRF bypass"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…