CVE-2026-44338 PraisonAI 身份验证绕过实验环境

用于 CVE-2026-44338（PraisonAI 旧版 Flask API 服务器中的身份验证绕过漏洞）的本地 Docker 实验环境。

本实验环境演示了旧版 API 路由上的未认证访问条件。它有意采用安全的路由级复现方式，而非完整的 PraisonAI 部署，从而使验证过程聚焦于身份验证缺陷本身，不会触发真实的 agent 工作流或外部 LLM 调用。

概述

CVE-2026-44338 影响 PraisonAI >= 2.5.6 至 <= 4.6.33 版本。

在存在漏洞的旧版 API 服务器中，身份验证默认处于禁用状态。因此，任何能够访问该 API 服务器的未认证调用者都可以在无需 bearer token 的情况下访问 /agents 并触发 /chat 工作流路由。

该问题在 PraisonAI 4.6.34 中通过更改默认行为得到修复，现在除非显式禁用，否则默认要求进行身份验证。

根本原因

在受影响版本中，旧版 API 服务器使用了不安全的身份验证默认配置：

AUTH_ENABLED = False
AUTH_TOKEN = None

def check_auth():
    if not AUTH_ENABLED:
        return True

由于 check_auth() 在身份验证被禁用时返回 True，受保护的路由会默认放行（fail open）。

受影响的路由包括：

GET /agents
POST /chat

修复版本更改了默认安全姿态，除非通过配置显式禁用，否则身份验证始终处于启用状态。

源码级修复详情

核心问题并非复杂的漏洞利用原语，而是源自旧版 Flask API 服务器中不安全的默认配置。

`v4.6.33` 中的漏洞行为

在 v4.6.33 中，身份验证默认被禁用：

AUTH_ENABLED = False
AUTH_TOKEN = None

随后的身份验证检查会默认放行：

def check_auth():
    if not AUTH_ENABLED:
        return True

这意味着只要身份验证被禁用，请求就会被接受，即使调用者未发送 Authorization 头。

漏洞流程如下：

AUTH_ENABLED = False
        ↓
check_auth() returns True
        ↓
GET /agents is allowed
POST /chat is allowed
        ↓
unauthenticated caller can access agent metadata and reach the workflow trigger route

关键点在于 /chat 不仅仅是一个状态端点。它会接收用户消息，然后使用 agents.yaml 调用 PraisonAI 工作流运行器。

`v4.6.34` 中的修复行为

在 v4.6.34 中，默认行为被更改为要求进行身份验证，除非操作员显式禁用它：

AUTH_ENABLED = os.environ.get("PRAISONAI_API_AUTH", "enabled").strip().lower() != "disabled"
AUTH_TOKEN = os.environ.get("PRAISONAI_API_TOKEN") or None

修复版本还改进了 token 处理行为：

身份验证默认启用
禁用身份验证需要显式的配置选择
如果身份验证已启用但未提供 token，服务器会生成一个随机 token
token 比较使用 secrets.compare_digest()
API 服务器默认绑定到 127.0.0.1，而不是暴露在所有接口上

修复后的流程如下：

AUTH_ENABLED = True by default
        ↓
request must include a valid Bearer token
        ↓
missing or invalid token returns 401
        ↓
/agents and /chat are no longer reachable anonymously

本实验环境再现了这一源码层面的差异：

vuln    -> auth disabled by default, unauthenticated requests return 200
patched -> auth required by default, unauthenticated requests return 401

实验环境设计

该实验环境包含两个本地服务：

服务	URL	行为
`vuln`	`http://127.0.0.1:8081`	复现存在漏洞的默认放行身份验证行为
`patched`	`http://127.0.0.1:8082`	要求 bearer token 身份验证

两个服务都仅绑定到 127.0.0.1。

/chat 路由使用了一个模拟运行器，而非真实的 PraisonAI 工作流。这样可以提供可观察的证据，证明未认证请求能够到达工作流触发路径，同时不会产生外部副作用。

仓库结构

.
├── docker-compose.yml
├── vuln
│   ├── Dockerfile
│   └── start_server.py
├── patched
│   ├── Dockerfile
│   └── start_server.py
├── poc
│   └── poc.py
└── .gitignore
└── README.md

运行

docker compose up --build -d
python3 poc/poc.py

预期结果

存在漏洞的服务允许未认证访问：

=== vuln ===
[unauthenticated] GET /agents
status: 200

[unauthenticated] POST /chat
status: 200

verdict: LIKELY_VULNERABLE

已修复的服务会阻止未认证访问：

=== patched ===
[unauthenticated] GET /agents
status: 401

[unauthenticated] POST /chat
status: 401

verdict: NOT_VULNERABLE_OR_PROTECTED

最终预期摘要：

vuln:    LIKELY_VULNERABLE
patched: NOT_VULNERABLE_OR_PROTECTED

手动验证

检查存在漏洞的路由：

curl -i http://127.0.0.1:8081/agents

漏洞版本的预期响应：

HTTP/1.1 200 OK

检查已修复的路由：

curl -i http://127.0.0.1:8082/agents

修复版本的预期响应：

HTTP/1.1 401 UNAUTHORIZED

服务器日志应能清晰地显示差异：

vuln:    "GET /agents HTTP/1.1" 200
patched: "GET /agents HTTP/1.1" 401

清理

docker compose down -v

安全说明

本实验环境仅用于本地安全研究。

该 PoC 不会：

执行 shell 命令
使用真实的 API 密钥
调用外部 LLM 提供商
扫描外部网络
触发真实的 PraisonAI agent 工作流

参考链接

GitHub 安全公告：GHSA-6rmh-7xcm-cpxj https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-6rmh-7xcm-cpxj
NVD：CVE-2026-44338 https://nvd.nist.gov/vuln/detail/CVE-2026-44338
OSV：GHSA-6rmh-7xcm-cpxj https://osv.dev/vulnerability/GHSA-6rmh-7xcm-cpxj
存在漏洞的源码：PraisonAI v4.6.33 的 src/praisonai/api_server.py https://raw.githubusercontent.com/MervinPraison/PraisonAI/v4.6.33/src/praisonai/api_server.py
已修复的源码：PraisonAI v4.6.34 的 src/praisonai/api_server.py https://raw.githubusercontent.com/MervinPraison/PraisonAI/v4.6.34/src/praisonai/api_server.py

CVE-2026-44338-Lab

最受欢迎