cve-2026-105221-gist-tls

gist RubyGem < 6.1.0 - defunkt

http_connection définit OpenSSL::SSL::VERIFY_NONE. HTTPS vers GitHub chiffre toujours, mais n'importe quel certificat est accepté. Un pair sur le chemin peut lire le jeton OAuth que la CLI envoie, puis lire et modifier les gists de la victime.


ID	CVE-2026-105221
CWE	CWE-295
CVSS	Élevé : 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)
Produit	gist
Affecté	4.0.0 à 6.0.0. Version du labo 6.0.0. Corrigé dans 6.1.0 (`07ccc1a`).
Auth	MITM sur le chemin de la CLI gist
Licence	GNU Affero GPL v3.0
Labo	`127.0.0.1` uniquement

Ce qu'un attaquant peut faire

L'attaquant se place sur le chemin et récupère le jeton GitHub.

Présenter n'importe quel certificat TLS. gist 6.0.0 ne vérifie pas le pair. Un certificat auto-signé avec CN=mitm.invalid suffit.
Lire Authorization: token .... La connexion (gist --login) et les opérations d'envoi/liste/suppression de gist passent toutes par http_connection. Le jeton dans ~/.gist transite sur ce socket.
Lire et modifier les gists de la victime. Ce jeton est un identifiant OAuth GitHub avec le scope gist. Gists privés, mises à jour, suppressions.
Intercepter une connexion en vol. Le flux d'appareil et la connexion nom d'utilisateur/mot de passe atteignent GitHub via le même TLS non vérifié.

Ils ont besoin d'une position réseau : Wi-Fi hostile, un proxy, une machine au milieu. Il ne s'agit pas d'une RCE distante non authentifiée contre un serveur.

6.1.0 définit VERIFY_PEER. Le même faux certificat échoue avec certificate verify failed (self-signed certificate) et le jeton ne quitte jamais le client.

Comment je l'ai trouvé

VulnCheck a publié CVE-2026-105221. Siyang Wu l'a signalé. L'issue 373 est le ticket public. La PR 374 a inversé le mode de vérification. J'ai reproduit la CVE publique en labo. Il n'y avait pas de PoC public.

lib/gist.rb http_connection sur 6.0.0 :

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

6.1.0 est VERIFY_PEER.

Le labo en boucle locale est un faux stub HTTPS GitHub Enterprise avec un certificat auto-signé. GITHUB_URL=https://127.0.0.1:8443 place gist en mode GHE (POST /api/v3/gists). Un jeton de labo CVE-2026-105221-WITNESS se trouve dans le fichier ~/.gist.* correspondant. gist 6.0.0 termine le TLS, le stub capture Authorization: token CVE-2026-105221-WITNESS et écrit le témoin. gist 6.1.0 contre le même stub échoue au TLS. Le compteur de captures sur 6.1.0 reste à zéro. Rien ne communique avec api.github.com.

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

Fausses pistes déjà enregistrées : aucune. Le premier run.sh a affiché SUCCESS. Un reverse shell. Du théâtre. L'oracle est le jeton de labo capturé sur 6.0.0 et l'erreur TLS auto-signée sur 6.1.0.

Labo

cd lab
./run.sh

Cible uniquement https://127.0.0.1:18210 (conteneur 8443). run.sh installe gist 6.0.0 et 6.1.0 depuis RubyGems, sert le stub à l'intérieur du conteneur, puis démonte la pile. Certificat auto-signé. Pas de vrai GitHub.

cve-2026-105221-gist-tls

Populaires

cve-2026-105221-gist-tls

Ce qu'un attaquant peut faire

Comment je l'ai trouvé

Labo

Le correctif

Références

Licence