Skip to content
KitploitKITPLOIT
工具博客
提交
工具博客
提交

黑客、渗透测试和网络安全工具,武装您的安全武器库!

Kitploit 是一个黑客、网络安全和渗透测试工具的目录。发现最新的项目更新,查找漏洞、分析系统、自动化测试并加强你的安全。

··订阅源·联系·隐私·© 2026 Kitploit

工具目录

分类

查看所有分类
Loading categories
CVE-2026-26198-analysis — 深入剖析 Python Ormar ORM 中的一个严重 SQL 注入漏洞——复现、修复与测试 | Kitploit
工具/GitHubGitHub/sergicortesabadia/cve-2026-26198-analysis
漏洞分析代码分析Web安全论文与研究学习与教育
GitHubsergicortesabadia/cve-2026-26198-analysis

CVE-2026-26198-analysis

深入剖析 Python Ormar ORM 中的一个严重 SQL 注入漏洞——复现、修复与测试

查看仓库
5个月前尚未审核

最受欢迎

查看全部 →

发现我们社区最常用的工具。

探索所有工具

浏览我们的工具集合

查看所有工具 →
分享

CVE-2026-26198 — Ormar ORM 中的 SQL 注入漏洞

深入剖析 Python 异步 ORM 中的一个严重(CVSS 9.8)SQL 注入漏洞,包括复现、分析与修复。

漏洞详情

Ormar 是一个流行的 Python 异步迷你 ORM,常与 FastAPI 和 Starlette 搭配使用。0.9.9 至 0.22.0 版本中的 min() 和 max() 聚合方法存在 SQL 注入漏洞。

根本原因是一个“部分实现”缺陷:虽然 sum() 和 avg() 会验证列参数是否指向实际的数字字段,但 min() 和 max() 完全跳过了这一检查,直接将用户输入传入 sqlalchemy.text() —— 一个原始 SQL 汇点。

攻击者可以将子查询作为“列”参数注入:

root@kitploit:~
# 预期用法
await Item.objects.max("price")  # → SELECT max(price) FROM items

# 攻击载荷
await Item.objects.max("(SELECT password FROM users LIMIT 1)")
# → SELECT max((SELECT password FROM users LIMIT 1)) FROM items
# 返回管理员的密码!

快速概览

属性值
CVE IDCVE-2026-26198
CVSS 评分9.8(严重)
CWECWE-89:SQL 注入
受影响版本ormar 0.9.9 – 0.22.0
修复版本ormar 0.23.0
发布时间2026 年 2 月 24 日
需要认证?否 —— 无需认证

项目结构

root@kitploit:~
├── README.md               ← 你在这里
├── vulnerable_app.py       ← 包含漏洞模式的最小 FastAPI 应用
├── exploit_demo.py         ← 展示注入过程的安全 PoC
├── patched_app.py          ← 带输入验证的修复版本
├── test_vulnerability.py   ← 证明漏洞存在且修复有效的测试
├── requirements.txt
└── analysis/
    └── root_cause.md       ← 详细的代码级漏洞分析

运行演示

root@kitploit:~
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

# 运行测试(无需外部数据库 —— 使用 SQLite)
python -m pytest test_vulnerability.py -v

# 运行交互式漏洞利用演示
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)
  • NVD 条目
  • Ormar 仓库

许可证

MIT

下载工具