sergicortesabadia/CVE-2026-26198-analysis
GitHub: sergicortesabadia/CVE-2026-26198-analysis
深度剖析 Python Ormar ORM 中 min/max 聚合方法的 SQL 注入漏洞,提供完整复现环境、根因分析和白名单修复方案。
Stars: 0 | Forks: 0
# CVE-2026-26198 — Ormar ORM 中的 SQL 注入
**深入解析 Python 异步 ORM 中的一个严重(CVSS 9.8)SQL 注入漏洞,包含复现、分析和修复方案。**
## 漏洞说明
[Ormar](https://github.com/collerek/ormar) 是一个流行的 Python 异步 mini ORM,常与 FastAPI 和 Starlette 配合使用。版本 **0.9.9 到 0.22.0** 在 `min()` 和 `max()` 聚合方法中存在 SQL 注入漏洞。
根本原因是一个“部分实现”缺陷:虽然 `sum()` 和 `avg()` 会验证列参数是否指向实际的数值字段,但 `min()` 和 `max()` 完全跳过了此检查,直接将用户输入传递给 `sqlalchemy.text()` —— 一个原始 SQL 接收点。
攻击者可以将子查询作为“column”参数注入:
```
# 预期用法
await Item.objects.max("price") # → SELECT max(price) FROM items
# 攻击 payload
await Item.objects.max("(SELECT password FROM users LIMIT 1)")
# → SELECT max((SELECT password FROM users LIMIT 1)) FROM items
# 返回 admin 的密码!
```
## 速览
| 属性 | 值 |
|-----------------|------------------------------------------|
| **CVE ID** | CVE-2026-26198 |
| **CVSS 评分** | 9.8 (严重) |
| **CWE** | CWE-89: SQL 注入 |
| **受影响版本** | ormar 0.9.9 – 0.22.0 |
| **修复版本** | ormar 0.23.0 |
| **发布日期** | 2026年2月24日 |
| **需要认证?** | 无需认证 |
## 项目结构
```
├── README.md ← You are here
├── vulnerable_app.py ← Minimal FastAPI app with the vulnerable pattern
├── exploit_demo.py ← Safe PoC showing the injection in action
├── patched_app.py ← The fixed version with input validation
├── test_vulnerability.py ← Tests proving the vuln exists and the fix works
├── requirements.txt
└── analysis/
└── root_cause.md ← Detailed code-level analysis of the bug
```
## 运行演示
```
git clone https://github.com/YOUR_USERNAME/CVE-2026-26198-analysis.git
cd CVE-2026-26198-analysis
python -m venv venv && source venv/bin/activate
pip install -r requirements.txt
# 运行测试(无需外部 DB — 使用 SQLite)
python -m pytest test_vulnerability.py -v
# 运行交互式 exploit 演示
python exploit_demo.py
```
## 修复方案
该修复方案在列参数到达 `sqlalchemy.text()` 之前,会验证其是否与模型上的实际字段匹配。这是通过**白名单方法**实现的:仅允许存在于模型字段定义中的列名。
请参阅 `patched_app.py` 了解实现细节,以及 `analysis/root_cause.md` 获取完整分析。
## 关键要点
1. **ORM 并非自动的 SQL 注入防护盾。** 如果一个 ORM 方法接受原始字符串并将其传递给文本子句,这与其编写原始 SQL 一样危险。
2. **部分验证比不验证更糟糕。** `sum()`/`avg()` 经过了验证而 `min()`/`max()` 没有,这种差异制造了虚假的安全感。
3. **使用白名单,而非黑名单。** 修复方案是根据已知的合法列名进行验证,而不是试图过滤恶意模式。
## 参考资料
- [GitHub 安全公告 (GHSA-xxh2-68g9-8jqr)](https://github.com/collerek/ormar/security/advisories/GHSA-xxh2-68g9-8jqr)
- [NVD 条目](https://nvd.nist.gov/vuln/detail/CVE-2026-26198)
- [Ormar 仓库](https://github.com/collerek/ormar)
## 许可证
MIT
标签:API密钥检测, AV绕过, CISA项目, CVE-2026-26198, CVSS 9.8, CWE-89, FastAPI, Ormar, ORM安全, PoC, Python, SQLAlchemy, 安全漏洞, 安全规则引擎, 异步ORM, 无后门, 暴力破解, 漏洞复现, 输入验证, 逆向工具