cve-2026-105221-gist-tls

gist RubyGem < 6.1.0 - defunkt

http_connection imposta OpenSSL::SSL::VERIFY_NONE. HTTPS verso GitHub cifra comunque, ma qualsiasi certificato viene accettato. Un peer on-path può leggere il token OAuth che la CLI invia, quindi leggere e modificare i gist della vittima.


ID	CVE-2026-105221
CWE	CWE-295
CVSS	High: 7.4 `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N` (VulnCheck 4.0: 9.1)
Prodotto	gist
Affetto	dalla 4.0.0 alla 6.0.0. Pin del lab 6.0.0. Corretto in 6.1.0 (`07ccc1a`).
Auth	MITM on-path della CLI gist
Licenza	GNU Affero GPL v3.0
Lab	solo `127.0.0.1`

Cosa può fare un attaccante

L'attaccante si trova sul percorso e si impossessa del token GitHub.

Presentare qualsiasi certificato TLS. gist 6.0.0 non verifica il peer. Un certificato self-signed con CN=mitm.invalid è sufficiente.
Leggere Authorization: token .... Il login (gist --login) e le operazioni di upload/list/delete di gist passano tutte attraverso http_connection. Il token in ~/.gist viaggia su quel socket.
Leggere e modificare i gist della vittima. Quel token è una credenziale OAuth di GitHub con lo scope gist. Gist privati, aggiornamenti, cancellazioni.
Catturare un login in transito. Il device-flow e il login username/password raggiungono GitHub sulla stessa TLS non verificata.

Serve una posizione di rete: Wi-Fi ostile, un proxy, una macchina nel mezzo. Non si tratta di RCE remoto non autenticato contro un server.

La 6.1.0 imposta VERIFY_PEER. Lo stesso certificato fasullo muore con certificate verify failed (self-signed certificate) e il token non lascia mai il client.

Come l'ho trovato

VulnCheck ha pubblicato CVE-2026-105221. Siyang Wu l'ha segnalato. Issue 373 è il ticket pubblico. PR 374 ha invertito la modalità di verifica. Ho riprodotto in lab la CVE pubblica. Non esisteva alcun PoC pubblico.

lib/gist.rb http_connection sulla 6.0.0:

if uri.scheme == "https"
  connection.use_ssl = true
  connection.verify_mode = OpenSSL::SSL::VERIFY_NONE
end

La 6.1.0 usa VERIFY_PEER.

Il lab su loopback è uno stub HTTPS finto di GitHub Enterprise con un certificato self-signed. GITHUB_URL=https://127.0.0.1:8443 mette gist in modalità GHE (POST /api/v3/gists). Un token di lab CVE-2026-105221-WITNESS risiede nel file ~/.gist.* corrispondente. gist 6.0.0 completa la TLS, lo stub cattura Authorization: token CVE-2026-105221-WITNESS e scrive il witness. gist 6.1.0 contro lo stesso stub fallisce la TLS. Il conteggio delle catture sulla 6.1.0 resta zero. Nulla comunica con api.github.com.

SUCCESS CVE-2026-105221 vuln-tls=ok token-captured=1 patched-tls=fail witness-written=yes CVE-2026-105221-WITNESS

Vicoli ciechi già registrati: nessuno. Il primo run.sh ha stampato SUCCESS. Una reverse shell. Teatro. L'oracolo è il token di lab catturato sulla 6.0.0 e l'errore TLS self-signed sulla 6.1.0.

Lab

cd lab
./run.sh

Target solo https://127.0.0.1:18210 (container 8443). run.sh installa gist 6.0.0 e 6.1.0 da RubyGems, serve lo stub all'interno del container, quindi smonta lo stack. Certificato self-signed. Nessun GitHub reale.

cve-2026-105221-gist-tls

Più Popolari

cve-2026-105221-gist-tls

Cosa può fare un attaccante

Come l'ho trovato

Lab

La correzione

Riferimenti

Licenza