cve-2026-105221-gist-tls

gist RubyGem < 6.1.0 - defunkt

Klasse: TLS-Verify-Bypass (Diebstahl von Anmeldedaten) Reichweite: Remote (On-Path)

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


ID	CVE-2026-105221
Klasse	TLS-Verify-Bypass (Diebstahl von Anmeldedaten)
Reichweite	Remote (On-Path)
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 entwendet das GitHub-Token.

Jedes TLS-Zertifikat präsentieren. gist 6.0.0 prüft das Gegenüber 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-Anmeldedaten mit dem Scope gist. Private Gists, Updates, Löschungen.
Einen Login im Flug abfangen. Device-Flow- und Benutzername/Passwort-Login erreichen GitHub über dasselbe ungeprüfte TLS.

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

6.1.0 setzt VERIFY_PEER. Dasselbe gefälschte Zertifikat scheitert 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 nachgestellt. Es gab kein öffentliches 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 erfasst Authorization: token CVE-2026-105221-WITNESS und schreibt den Witness. gist 6.1.0 scheitert gegen denselben Stub an TLS. Die Capture-Anzahl bei 6.1.0 bleibt null. Nichts kommuniziert mit api.github.com.

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

Falsche Abzweigungen bereits aufgezeichnet: keine. Das erste run.sh gab SUCCESS aus. Eine Reverse Shell. Theater. Das Orakel ist das erbeutete Lab-Token auf 6.0.0 und der selbstsignierte TLS-Fehler auf 6.1.0.

Lab

cd lab
./run.sh

Nur https://127.0.0.1:18210 anvisieren (Container 8443). run.sh installiert gist 6.0.0 und 6.1.0 von RubyGems, stellt den Stub innerhalb des Containers bereit 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

Die Behebung

Referenzen

Lizenz