cve-2026-105221-gist-tls

gist RubyGem < 6.1.0 - defunkt

Classe: bypass della verifica TLS (furto di credenziali) Portata: remota (on-path)

http_connection imposta OpenSSL::SSL::VERIFY_NONE. L'HTTPS verso GitHub resta cifrato, ma qualsiasi certificato viene accettato. Un peer on-path può leggere il token OAuth inviato dalla CLI, quindi leggere e modificare i gist della vittima.


ID	CVE-2026-105221
Classe	Bypass della verifica TLS (furto di credenziali)
Portata	Remota (on-path)
CWE	CWE-295
CVSS	Alto: 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
Affette	dalla 4.0.0 alla 6.0.0. Pin del lab 6.0.0. Corretta nella 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 cattura il token GitHub.

Presentare qualsiasi certificato TLS. gist 6.0.0 non verifica il peer. Basta un certificato self-signed con CN=mitm.invalid.
Leggere Authorization: token .... Il login (gist --login) e le operazioni di upload/list/delete dei gist passano tutti da 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.
Intercettare un login in corso. Il device-flow e il login con username/password raggiungono GitHub sullo stesso TLS non verificato.

Serve una posizione di rete: Wi-Fi ostile, un proxy, una macchina nel mezzo. Non si tratta di RCE remota non autenticata 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 trovata

VulnCheck ha pubblicato CVE-2026-105221. L'ha segnalata Siyang Wu. Issue 373 è il ticket pubblico. PR 374 ha invertito la modalità di verifica. Ho riprodotto in laboratorio 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

6.1.0 è VERIFY_PEER.

Il laboratorio loopback è uno stub HTTPS fittizio 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 laboratorio CVE-2026-105221-WITNESS risiede nel file corrispondente ~/.gist.*. gist 6.0.0 completa il TLS, lo stub cattura Authorization: token CVE-2026-105221-WITNESS e scrive il witness. gist 6.1.0 contro lo stesso stub fallisce il TLS. Il conteggio delle catture su 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

Nessuna deviazione già registrata. Il primo run.sh ha stampato SUCCESS. Una reverse shell. Teatro. L'oracolo è il token di laboratorio catturato su 6.0.0 e l'errore TLS self-signed su 6.1.0.

Lab

cd lab
./run.sh

Prendi di mira 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 trovata

Lab

La correzione

Riferimenti

Licenza