SSRF (Server-Side Request Forgery) in ssrf (CVE-2026-44335)
Summary
SSRF in ssrf (CVE-2026-44335). Successful exploitation can lead to full system takeover. Exploitable via requests. Mitigation: upgrade to >= 1.6.32 or later.
Original description
The description as published by the source.
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.
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.
In reality, its underlying mechanism is requests.get.
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 as1.1.1.1(public)requeststreats\as a path character, connecting to127.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["err…
Source: NIST National Vulnerability Database NVD GitHub Advisory
AI summary
Written by an external AI model and may contain mistakes. Check the original description and references below before acting on it.
In older versions of PraisonAI, crafted URLs might bypass security checks, allowing attackers to gain unauthorized access to internal networks, a type of attack known as "Server-Side Request Forgery." Upgrading to version 1.6.32 or later is recommended as this has already caused issues in many systems previously, especially when handling sensitive data.
Technically, the flaw allows SSRF by exploiting differences between urlparse and requests.get when parsing URLs in _validate_url, specifically using formats like http://127.0.0.1:6666\@1.1.1.1. Affected versions are <= 1.6.31, and the issue is fixed in 1.6.32. Interim measures could involve tightening URL validation, but a swift update is optimal.
URLチェックロジックの欠陥
URLチェックにおける'validate_url'関数
critical (CVSS 9.8) - リモート攻撃可能、認証不要、ユーザー操作不要
バージョン1.6.32以上にアップグレードしてください
素材から特定できず
素材から特定できず
Related past incidents Similar incidents extracted from past CVEs
Apache StrutsでのSSRF問題で、URLパラメータを利用した攻撃が可能だった。
Apache Log4jの設定不備によるリモート攻撃 (SSRF)。
Apache TomcatにおけるURL処理の弱点がSSRFの脅威となった。
If this happens at your company Expected impact per business scenario
予期しないURL請求で内部サーバー情報が公開され、取引先との信頼が損なわれる可能性があります。
不正アクセスにより顧客情報が漏洩し、コンプライアンス上の問題を引き起こします。
内部ネットワークアクセスにより不正送金が可能になり、組織の経済的損失をもたらす可能性がある。
可能な限り迅速にPraisonAIをバージョン1.6.32以上へアップグレードすることが最善策です。
Response actions
Concrete steps and command examples for SOC/SRE teams to execute in order
-
1Identify exposure identify
grep -r 'ssrf' . | grep -v node_modulesリポジトリと本番環境の依存ファイル (package-lock.json / requirements.txt / go.sum / Gemfile.lock 等) で
ssrfを grep し、稼働しているサービス・バージョンを把握する。 -
2Match against affected range verify
Confirm if version satisfies `<= 1.6.31`Step 1 で見つかったバージョンが影響範囲
<= 1.6.31に該当するか照合。本番で稼働中ならインシデント扱い。 -
6Apply patch patch
Upgrade ssrf to >= 1.6.32ステージング環境で >= 1.6.32 に上げて回帰テスト → 本番反映。回帰テストはアプリの主要ハッピーパスと、Step 3 で見つけた異常検知の続報チェックを含めること。
-
7Post-deployment verification verify
Confirm patched version is live in productionパッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番では Step 3 と同じログクエリでアラート再発が無いか継続監視。
Affected packages
References
- advisory nvd.nist.gov
- package github.com
- web github.com
- web github.com