abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  cve-2026-105221-gist-tls

cve-2026-105221-gist-tls

gist RubyGem < 6.1.0 - defunkt

Clase: omisión de verificación TLS (robo de credenciales) Alcance: remoto (en la ruta)

http_connection establece OpenSSL::SSL::VERIFY_NONE. HTTPS hacia GitHub sigue cifrando, pero se acepta cualquier certificado. Un par en la ruta puede leer el token OAuth que envía la CLI y luego leer y modificar los gists de la víctima.

ID	CVE-2026-105221
Clase	Omisión de verificación TLS (robo de credenciales)
Alcance	Remoto (en la ruta)
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)
Producto	gist
Afectados	4.0.0 hasta 6.0.0. Versión fijada en el laboratorio 6.0.0. Corregido en 6.1.0 (07ccc1a).
Autenticación	MITM en la ruta de la CLI de gist
Licencia	GNU Affero GPL v3.0
Laboratorio	solo 127.0.0.1

Qué puede hacer un atacante

El atacante se sitúa en la ruta y captura el token de GitHub.

• Presentar cualquier certificado TLS. gist 6.0.0 no verifica al par. Basta un certificado autofirmado con CN=mitm.invalid.
• Leer Authorization: token .... El inicio de sesión (gist --login) y las operaciones de subida, listado y borrado de gists pasan por http_connection. El token en ~/.gist viaja por ese socket.
• Leer y editar los gists de la víctima. Ese token es una credencial OAuth de GitHub con el alcance gist. Gists privados, actualizaciones, borrados.
• Interceptar un inicio de sesión en tránsito. El inicio de sesión por device-flow y por usuario/contraseña llega a GitHub a través del mismo TLS no verificado.

Necesitan una posición en la red: Wi-Fi hostil, un proxy, un equipo intermedio. No es un RCE remoto no autenticado contra un servidor.

6.1.0 establece VERIFY_PEER. El mismo certificado falso falla con certificate verify failed (self-signed certificate) y el token nunca sale del cliente.

Cómo lo encontré

VulnCheck publicó CVE-2026-105221. Siyang Wu lo reportó. Issue 373 es el ticket público. PR 374 cambió el modo de verificación. Reproduje el CVE público en el laboratorio. No había PoC público.

lib/gist.rb http_connection en 6.0.0:

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

6.1.0 es VERIFY_PEER.

El laboratorio de loopback es un stub HTTPS falso de GitHub Enterprise con un certificado autofirmado. GITHUB_URL=https://127.0.0.1:8443 pone a gist en modo GHE (POST /api/v3/gists). Un token de laboratorio CVE-2026-105221-WITNESS se encuentra en el archivo ~/.gist.* correspondiente. gist 6.0.0 completa TLS, el stub captura Authorization: token CVE-2026-105221-WITNESS y escribe el testigo. gist 6.1.0 contra el mismo stub falla en TLS. El conteo de capturas en 6.1.0 permanece en cero. Nada se 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

Giros incorrectos ya registrados: ninguno. El primer run.sh imprimió SUCCESS. Una reverse shell. Teatro. El oráculo es el token de laboratorio capturado en 6.0.0 y el error TLS autofirmado en 6.1.0.

Laboratorio

cd lab
./run.sh

Dirígete solo a https://127.0.0.1:18210 (contenedor 8443). run.sh instala gist 6.0.0 y 6.1.0 desde RubyGems, sirve el stub dentro del contenedor y luego desmonta la pila. Certificado autofirmado. Sin GitHub real.

La solución

Actualiza la gema gist a 6.1.0 o posterior.

Referencias

• CVE-2026-105221
• NVD
• defunkt/gist etiquetas v6.0.0 / v6.1.0
• Issue 373
• PR 374 / 07ccc1a
• lib/gist.rb v6.0.0 L466-L468
• CWE-295

Licencia

GNU Affero GPL v3.0