cve-2026-105221-gist-tls

gist RubyGem < 6.1.0 - defunkt

http_connection 设置了 OpenSSL::SSL::VERIFY_NONE。到 GitHub 的 HTTPS 仍然加密，但接受任何证书。路径上的对等方可以读取 CLI 发送的 OAuth 令牌，然后读取和更改受害者的 gists。


ID	CVE-2026-105221
CWE	CWE-295
CVSS	High: 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)
Product	gist
Affected	4.0.0 through 6.0.0. Lab pin 6.0.0. Fixed in 6.1.0 (`07ccc1a`).
Auth	on-path MITM of the gist CLI
License	GNU Affero GPL v3.0
Lab	`127.0.0.1` only

攻击者能做什么

攻击者位于路径上并获取 GitHub 令牌。

出示任意 TLS 证书。 gist 6.0.0 不检查对等方。一个带有 CN=mitm.invalid 的自签名证书就足够了。
读取 Authorization: token ...。 登录（gist --login）以及 gist 上传/列出/删除都经过 http_connection。~/.gist 中的令牌就搭载在该套接字上。
读取和编辑受害者的 gists。 该令牌是具有 gist 范围的 GitHub OAuth 凭据。私有 gists、更新、删除。
在传输中捕获登录。 设备流和用户名/密码登录都通过同一个未验证的 TLS 访问 GitHub。

他们需要网络位置：恶意 Wi-Fi、代理、中间的一台机器。这不是针对服务器的未认证远程 RCE。

6.1.0 设置了 VERIFY_PEER。同样的伪造证书会以 certificate verify failed (self-signed certificate) 失败，令牌永远不会离开客户端。

我是如何发现的

VulnCheck 发布了 CVE-2026-105221。Siyang Wu 报告了它。Issue 373 是公开工单。PR 374 翻转了验证模式。我在实验室中复现了这个公开 CVE。当时没有公开的 PoC。

lib/gist.rb 中 6.0.0 的 http_connection：

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

6.1.0 是 VERIFY_PEER。

回环实验室是一个伪造的 GitHub Enterprise HTTPS 桩，带有自签名证书。GITHUB_URL=https://127.0.0.1:8443 让 gist 进入 GHE 模式（POST /api/v3/gists）。一个实验室令牌 CVE-2026-105221-WITNESS 位于匹配的 ~/.gist.* 文件中。gist 6.0.0 完成 TLS，桩捕获 Authorization: token CVE-2026-105221-WITNESS 并写入见证。gist 6.1.0 针对同一桩时 TLS 失败。6.1.0 上的捕获计数保持为零。没有任何东西与 api.github.com 通信。

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

已记录的弯路：无。第一次 run.sh 就打印了 SUCCESS。一个反向 shell。做戏。判定标准是 6.0.0 上捕获的实验室令牌，以及 6.1.0 上的自签名 TLS 错误。

实验室

cd lab
./run.sh

目标仅为 https://127.0.0.1:18210（容器 8443）。run.sh 从 RubyGems 安装 gist 6.0.0 和 6.1.0，在容器内提供桩服务，然后拆除整个栈。自签名证书。没有真实的 GitHub。

cve-2026-105221-gist-tls

最受欢迎

cve-2026-105221-gist-tls

攻击者能做什么

我是如何发现的

实验室

修复

参考

许可证