CVE-2026-53583

The CVSS 6.5 on CVE-2026-53583 obscures a complete certificate validation bypass in libgit2's OpenSSL backend. The bug is a single inverted boolean in IP-literal HTTPS URL validation: when comparing the certificate's SubjectAltName IP against the target connection IP, the comparison result gets logically flipped. A certificate with any IP in its SAN will validate successfully against connections to different IPs, while a certificate matching the actual target IP will fail validation—the exact opposite of correct behavior. The exploit barrier is deceptively low. An attacker needs only one CA-trusted certificate containing any IP address in its SubjectAltName. That single cert then works against any IP-literal HTTPS URL in any libgit2 deployment. You acquire the cert once; you own the blast radius everywhere. In environments with internal PKIs or legacy certificate templates with loose IP constraints, obtaining such a cert is operational trivia, not a sophisticated requirement. DNS SubjectAltName validation and non-OpenSSL TLS backends (mbedTLS, SecureTransport, Gnutls) implement this correctly. The correct logic sits three code blocks away from the bug, suggesting this was a specific regression in the OpenSSL codepath—possibly a porting error when that backend was written, or a later inversion that went unnoticed because surrounding code worked fine. The technical scope is narrow (IP-literal URLs only), but the operational scope is not. Corporate networks with strict segmentation, CI/CD pipelines connecting to fixed infrastructure IPs, and infrastructure-as-code tools hitting fixed endpoints are the exposed surface. These are exactly the environments where a CA-trusted cert with an arbitrary IP SAN would have the highest collateral value. The CVSS underrates this for the population that actually uses IP-literal HTTPS URLs with libgit2—narrow but security-conscious. Check your tooling: verify which TLS backend libgit2 was compiled against, audit whether IP-literal HTTPS URLs appear in your git operations, and ensure you're on a patched version. If you rely on libgit2 in embedded contexts, the version you ship may be older than what your distribution packages—audit your dependency tree.

Reviewed through automated stages and approved by a human before publication.