ssrf に SSRF (サーバー側リクエスト偽造)(CVE-2026-44335・CVSS 9.8)

概要

ssrf に SSRF (CVE-2026-44335) が存在。悪用されるとシステム全体を乗っ取られる可能性があります。requests 経由で攻撃可能。対策: >= 1.6.32 以上に更新。

原文の説明

取得元が公開している説明をそのまま載せています (多くは英語)。

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 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["err…

出典: NIST National Vulnerability Database NVD GitHub Advisory

AI要約

外部の AI が作成した要約です。誤りを含むことがあります。重要な判断の前に、下の原文と参照URLを確認してください。

PraisonAIの古いバージョンでは、特定の方式で作成されたURLが正しく検出されないため、攻撃者が内部ネットワークに不正アクセスできる問題があります。これは「サーバーサイドリクエストフォージェリ」と呼ばれる攻撃で、修正済みのバージョン1.6.32以上へのバージョンアップが推奨されます。この攻撃は過去にも多くのシステムで問題となっており、特に重要なデータを扱う場合は注意が必要です。

技術的には、「_validate_url」でのホスト部分の検証において「urlparse」と「requests.get」におけるパース方法の違いを悪用し、SSRF攻撃を可能にします。影響を受けるのはバージョン1.6.31以下で、バージョン1.6.32で修正されています。脆弱なエンドポイントに「http://127.0.0.1:6666@1.1.1.1」といったURLを利用することで、この脆弱性を使ってローカルへのアクセスを達成可能です。暫定対策として、URLチェックの強化が考えられますが、迅速なアップデートが最適です。

❓ 何が問題か

ssrf に SSRF (サーバー側リクエスト偽造) (CWE-918) があります。攻撃者は requests を経由して脆弱な処理に到達し、認証なしで悪用できます。

📍 影響範囲

ssrf のうち影響範囲: <= 1.6.31。攻撃箇所: requests。

🔥 重要度

重要度: 最重要 (CVSS 9.8/10)。悪用されるとシステム全体を乗っ取られる可能性があります

🔧 修正方法

>= 1.6.32 に更新してください。(修正前: <= 1.6.31 該当バージョンが本番稼働中なら直ちに更新計画を立案)

🛡️ 暫定回避

修正版が未提供時は、影響機能の無効化・WAFルール・ネットワークACLでの遮断を検討。

🔍 検知方法

Webサーバ・プロキシ・WAFログで該当CVEのIOCに合致する不審リクエストを検索。SBOM/依存ファイルで影響バージョンを横断確認。

類似する過去の事例過去のCVE/インシデントから類似事例を抽出

CVE-2018-11776

Apache StrutsでのSSRF問題で、URLパラメータを利用した攻撃が可能だった。

CVE-2021-45046

Apache Log4jの設定不備によるリモート攻撃 (SSRF)。

CVE-2019-0232

Apache TomcatにおけるURL処理の弱点がSSRFの脅威となった。

もし自社で起きたら業務シナリオごとの想定影響

📌 ECサイトのSME（Small and Medium Enterprises）で

予期しないURL請求で内部サーバー情報が公開され、取引先との信頼が損なわれる可能性があります。

📌 社内システムでのCRMへのアクセス制御が不十分な場合

不正アクセスにより顧客情報が漏洩し、コンプライアンス上の問題を引き起こします。

📌 金融業におけるバックエンドシステム

内部ネットワークアクセスにより不正送金が可能になり、組織の経済的損失をもたらす可能性がある。

推奨アクション

可能な限り迅速にPraisonAIをバージョン1.6.32以上へアップグレードすることが最善策です。

対応アクション

SOC/SREチームが順番に実行すべき具体的なステップとコマンド例

1
影響範囲の特定 identify
```
grep -r 'ssrf' . | grep -v node_modules
```
リポジトリと本番環境の依存ファイル (package-lock.json / requirements.txt / go.sum / Gemfile.lock 等) で ssrf を grep し、稼働しているサービス・バージョンを把握する。
2
バージョン照合 verify
```
Confirm if version satisfies `<= 1.6.31`
```
Step 1 で見つかったバージョンが影響範囲 <= 1.6.31 に該当するか照合。本番で稼働中ならインシデント扱い。
6
パッチ適用 patch
```
Upgrade ssrf to >= 1.6.32
```
ステージング環境で >= 1.6.32 に上げて回帰テスト → 本番反映。回帰テストはアプリの主要ハッピーパスと、Step 3 で見つけた異常検知の続報チェックを含めること。
7
事後検証 verify
```
Confirm patched version is live in production
```
パッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番では Step 3 と同じログクエリでアラート再発が無いか継続監視。

影響パッケージ

pip praisonaiagents

[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.6.32"}]}]

PyPI praisonaiagents