CVE-2026-73160

This CVE exposes a classic SSRF gap in cti-transmute: the developers implemented validation for IP literals (blocking private, loopback, and reserved ranges including IPv6) but skipped the equivalent check for hostnames. The fix adds socket.getaddrinfo() to resolve hostnames before the request is issued, which closes the immediate technical gap. However, the deeper lesson is about what 'partial security' costs you. The IP validation logic shows deliberate, knowledgeable effort — not casual negligence. The developer understood SSRF mitigation well enough to block IPv4 and IPv6 loopback/link-local addresses. What they missed is the equally well-documented step of resolving DNS before validating. This is a 'local maximum' problem: the developer optimized correctly within a scope that was itself too narrow, treating 'things that look like IP addresses' as the only untrusted input class. The secondary fix — adding @login_required — is informative. It suggests the maintainers recognized that unauthenticated callers could reach these endpoints, which means the hostname gap was exploitable by anyone, not just authenticated users. If the original deployment assumed internal-only access, the SSRF gap was theoretically present but practically constrained. That changes the severity calculus: the vulnerability existed in a specific configuration (externally exposed without auth), and the @login_required patch addresses that configuration exposure directly. For defenders, the actionable items: first, verify that any HTTP client library you use performs DNS resolution before sending requests — this should be a library-level guarantee, not an application-level addition. Second, audit your code for the 'IP literal vs. everything else' split in input handling; if you have explicit IP validation, assume you have implicit hostname vulnerability. Third, review whether endpoints with partial SSRF mitigation are exposed to unauthenticated callers — partial mitigation creates false confidence that the review process itself may not catch. The long-term structural fix is requiring a blessed HTTP client that enforces resolution-then-validate at the library level, removing the cognitive burden from individual developers.

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