cve-2026-105221-gist-tls

gist RubyGem < 6.1.0 - defunkt

http_connection setzt OpenSSL::SSL::VERIFY_NONE. HTTPS zu GitHub verschlüsselt zwar weiterhin, aber jedes Zertifikat wird akzeptiert. Ein Angreifer auf dem Pfad kann das OAuth-Token lesen, das die CLI sendet, und anschließend die Gists des Opfers lesen und ändern.


ID	CVE-2026-105221
CWE	CWE-295
CVSS	Hoch: 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)
Produkt	gist
Betroffen	4.0.0 bis 6.0.0. Lab-Pin 6.0.0. Behoben in 6.1.0 (`07ccc1a`).
Auth	On-Path-MITM der gist-CLI
Lizenz	GNU Affero GPL v3.0
Lab	nur `127.0.0.1`

Was ein Angreifer tun kann

Der Angreifer sitzt auf dem Pfad und stiehlt das GitHub-Token.

Jedes TLS-Zertifikat präsentieren. gist 6.0.0 prüft den Peer nicht. Ein selbstsigniertes Zertifikat mit CN=mitm.invalid genügt.
Authorization: token ... lesen. Login (gist --login) sowie gist-Upload/List/Delete laufen alle über http_connection. Das Token in ~/.gist reist über diesen Socket.
Die Gists des Opfers lesen und bearbeiten. Dieses Token ist eine GitHub-OAuth-Anmeldeinformation mit dem Scope gist. Private Gists, Updates, Löschungen.
Einen Login im Flug abfangen. Device-Flow- und Benutzername/Passwort-Login erreichen GitHub über dasselbe unverifizierte TLS.

Sie benötigen eine Netzwerkposition: feindseliges WLAN, ein Proxy, eine Box dazwischen. Dies ist kein unauthentifiziertes Remote-RCE gegen einen Server.

6.1.0 setzt VERIFY_PEER. Dasselbe gefälschte Zertifikat stirbt mit certificate verify failed (self-signed certificate) und das Token verlässt den Client nie.

Wie ich es gefunden habe

VulnCheck veröffentlichte CVE-2026-105221. Siyang Wu meldete es. Issue 373 ist das öffentliche Ticket. PR 374 stellte den Verify-Modus um. Ich habe die öffentliche CVE im Lab nachgebaut. Es gab keinen öffentlichen PoC.

lib/gist.rb http_connection in 6.0.0:

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

6.1.0 ist VERIFY_PEER.

Das Loopback-Lab ist ein gefälschter GitHub-Enterprise-HTTPS-Stub mit einem selbstsignierten Zertifikat. GITHUB_URL=https://127.0.0.1:8443 versetzt gist in den GHE-Modus (POST /api/v3/gists). Ein Lab-Token CVE-2026-105221-WITNESS liegt in der passenden ~/.gist.*-Datei. gist 6.0.0 schließt TLS ab, der Stub fängt Authorization: token CVE-2026-105221-WITNESS ab und schreibt den Witness. gist 6.1.0 scheitert gegen denselben Stub an TLS. Die Capture-Anzahl bleibt bei 6.1.0 null. Nichts spricht mit api.github.com.

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

Bereits dokumentierte Irrwege: keine. Das erste run.sh gab SUCCESS aus. Eine Reverse Shell. Theater. Das Orakel ist das abgefangene Lab-Token bei 6.0.0 und der selbstsignierte TLS-Fehler bei 6.1.0.

Lab

cd lab
./run.sh

Ziel ausschließlich https://127.0.0.1:18210 (Container 8443). run.sh installiert gist 6.0.0 und 6.1.0 von RubyGems, bedient den Stub innerhalb des Containers und baut den Stack anschließend ab. Selbstsigniertes Zertifikat. Kein echtes GitHub.

cve-2026-105221-gist-tls

Beliebteste

cve-2026-105221-gist-tls

Was ein Angreifer tun kann

Wie ich es gefunden habe

Lab

Der Fix

Referenzen

Lizenz