gist RubyGem CVE-2026-105221

Exploitation requires the attacker to hold an active on-path (man-in-the-middle) position on the network between the gist client and the GitHub API - this is the concrete limiting factor reflected by CVSS AC:H and AT:P. The defect itself needs no special product configuration: any invocation of the gist RubyGem before version 6.1.0 is vulnerable by default because lib/gist.rb's http_connection unconditionally sets OpenSSL::SSL::VERIFY_NONE, disabling TLS certificate validation for all HTTPS calls. No authentication is required of the attacker (PR:N) and no victim interaction beyond normally running the tool; the practical constraint is purely network adjacency, so risk is highest on untrusted or shared networks and negligible on fully trusted paths.

The CVSS 4.0 base score of 9.1 (Critical) is driven by high confidentiality and integrity impact (VC:H/VI:H) with network vector and no privileges required (AV:N/PR:N/UI:N), but two metrics materially lower the real-world risk: AC:H and AT:P both signal that exploitation requires the attacker to first achieve a privileged on-path/man-in-the-middle network position, which is not trivially automatable or opportunistic. No EPSS score was provided, the CVE is NOT on CISA KEV, and no public exploit code is referenced, so there is no evidence of active or widespread exploitation. This is best characterized as a genuine but conditional flaw: the impact is severe (OAuth token and credential theft against GitHub API traffic) yet exploitation is gated on network-adjacency, making it a targeted-threat concern (e.g., hostile Wi-Fi, compromised network paths) rather than a mass-exploitation priority. Note the signal contrast: a 9.1 'Critical' label overstates urgency here because the attack requirement (on-path position) is a significant real-world barrier that raw severity alone obscures.

A developer on an untrusted network (e.g., public Wi-Fi or a compromised corporate segment) runs the gist CLI, which connects to the GitHub API with TLS certificate verification disabled (VERIFY_NONE). An attacker already positioned on the network path presents a forged certificate, transparently intercepts the HTTPS session, and captures the OAuth token and login credentials, then reads or modifies the victim's gists. No public exploit code is referenced, but the attack is straightforward with standard MITM tooling given on-path access.