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

http_connection sets OpenSSL::SSL::VERIFY_NONE. HTTPS to GitHub still encrypts, but any certificate is accepted. An on-path peer can read the OAuth token the CLI sends, then read and change the victim's 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

What an attacker can do

The attacker sits on the path and takes the GitHub token.

• Present any TLS certificate. gist 6.0.0 does not check the peer. A self-signed cert with CN=mitm.invalid is enough.
• Read Authorization: token .... Login (gist --login) and gist upload/list/delete all go through http_connection. The token in ~/.gist rides that socket.
• Read and edit the victim's gists. That token is a GitHub OAuth credential with the gist scope. Private gists, updates, deletes.
• Catch a login in flight. Device-flow and username/password login hit GitHub over the same unverified TLS.

They need a network position: hostile Wi-Fi, a proxy, a box in the middle. This is not unauthenticated remote RCE against a server.

6.1.0 sets VERIFY_PEER. The same bogus cert dies with certificate verify failed (self-signed certificate) and the token never leaves the client.

How I found it

VulnCheck published CVE-2026-105221. Siyang Wu reported it. Issue 373 is the public ticket. PR 374 flipped the verify mode. I labbed the public CVE. There was no public PoC.

lib/gist.rb http_connection on 6.0.0:

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

6.1.0 is VERIFY_PEER.

The loopback lab is a fake GitHub Enterprise HTTPS stub with a self-signed cert. GITHUB_URL=https://127.0.0.1:8443 puts gist in GHE mode (POST /api/v3/gists). A lab token CVE-2026-105221-WITNESS sits in the matching ~/.gist.* file. gist 6.0.0 completes TLS, the stub captures Authorization: token CVE-2026-105221-WITNESS and writes the witness. gist 6.1.0 against the same stub fails TLS. Capture count on 6.1.0 stays zero. Nothing talks to api.github.com.

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

Wrong turns already recorded: none. First run.sh printed SUCCESS. A reverse shell. Theatre. The oracle is the captured lab token on 6.0.0 and the self-signed TLS error on 6.1.0.

Lab

cd lab
./run.sh

Target only https://127.0.0.1:18210 (container 8443). run.sh installs gist 6.0.0 and 6.1.0 from RubyGems, serves the stub inside the container, then tears the stack down. Self-signed cert. No real GitHub.

The fix

Upgrade the gist gem to 6.1.0 or later.

References

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

License

GNU Affero GPL v3.0