cve-2026-105221-gist-tls

gist RubyGem < 6.1.0 - defunkt

http_connection define OpenSSL::SSL::VERIFY_NONE. HTTPS para o GitHub ainda criptografa, mas qualquer certificado é aceito. Um par on-path pode ler o token OAuth que a CLI envia e, em seguida, ler e alterar os gists da vítima.


ID	CVE-2026-105221
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)
Produto	gist
Afetado	4.0.0 até 6.0.0. Fixado no lab 6.0.0. Corrigido em 6.1.0 (`07ccc1a`).
Auth	MITM on-path da CLI gist
Licença	GNU Affero GPL v3.0
Lab	somente `127.0.0.1`

O que um atacante pode fazer

O atacante fica no caminho e captura o token do GitHub.

Apresentar qualquer certificado TLS. O gist 6.0.0 não verifica o par. Um certificado autoassinado com CN=mitm.invalid é suficiente.
Ler Authorization: token .... Login (gist --login) e upload/list/delete de gists passam por http_connection. O token em ~/.gist trafega nesse socket.
Ler e editar os gists da vítima. Esse token é uma credencial OAuth do GitHub com o escopo gist. Gists privados, atualizações, exclusões.
Capturar um login em trânsito. Login por device-flow e por usuário/senha acessa o GitHub pela mesma TLS não verificada.

Eles precisam de uma posição na rede: Wi-Fi hostil, um proxy, uma máquina no meio. Isso não é RCE remoto não autenticado contra um servidor.

O 6.1.0 define VERIFY_PEER. O mesmo certificado falso morre com certificate verify failed (self-signed certificate) e o token nunca sai do cliente.

Como eu encontrei

A VulnCheck publicou CVE-2026-105221. Siyang Wu reportou. A Issue 373 é o ticket público. O PR 374 alterou o modo de verificação. Eu montei o lab da CVE pública. Não havia PoC público.

lib/gist.rb http_connection no 6.0.0:

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

O 6.1.0 é VERIFY_PEER.

O lab em loopback é um stub HTTPS falso do GitHub Enterprise com um certificado autoassinado. GITHUB_URL=https://127.0.0.1:8443 coloca o gist em modo GHE (POST /api/v3/gists). Um token de lab CVE-2026-105221-WITNESS fica no arquivo ~/.gist.* correspondente. O gist 6.0.0 completa o TLS, o stub captura Authorization: token CVE-2026-105221-WITNESS e grava o witness. O gist 6.1.0 contra o mesmo stub falha no TLS. A contagem de capturas no 6.1.0 permanece zero. Nada conversa com api.github.com.

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

Caminhos errados já registrados: nenhum. O primeiro run.sh imprimiu SUCCESS. Um reverse shell. Teatro. O oráculo é o token de lab capturado no 6.0.0 e o erro de TLS autoassinado no 6.1.0.

Lab

cd lab
./run.sh

Alvo somente https://127.0.0.1:18210 (container 8443). O run.sh instala o gist 6.0.0 e 6.1.0 do RubyGems, serve o stub dentro do container e depois derruba a stack. Certificado autoassinado. Nenhum GitHub real.

cve-2026-105221-gist-tls

Mais Populares

cve-2026-105221-gist-tls

O que um atacante pode fazer

Como eu encontrei

Lab

A correção

Referências

Licença