CVE-2026-58442

The phrase 'multi-answer DNS allow-list bypass' in this vulnerability description reveals a narrow, implementable flaw that most vulnerability scanners and static analysis tools likely missed. Here's what actually happened and why it probably persisted longer than the CVSS 6.5 rating suggests. During repository migration, the system takes a user-supplied hostname, resolves it to an IP address, checks that IP against an allow-list (blocking 10.x, 169.254.x, 127.x and similar RFC 1918/link-local ranges), then initiates the HTTP connection. The vulnerability: the code resolves all DNS answers, checks the first one against the allow-list, but then iterates through the entire response list when making the actual connection. An attacker registers a domain with two A records — first resolving to a legitimate public IP that passes the allow-list, second resolving to an internal IP like 169.254.169.254 or 10.0.0.1 — and the migration function fetches from internal infrastructure. This is not a timing attack or DNS rebinding race condition; it's a synchronous single-request exploit trivial to execute once identified. The multi-answer nature is precisely why automated detection failed. SAST tools analyzing the DNS resolution call in isolation wouldn't flag it because the vulnerable behavior only emerges at the intersection of the resolution logic and the connection logic across multiple code modules. The allow-list check and the HTTP client library (likely requests or urllib) were never integration-tested together with a crafted multi-answer DNS response. Determine whether your migration feature is pull-based (the platform fetches from user-supplied URLs) or push-based (the platform receives URLs from users), as the blast radius differs substantially. Verify whether the allow-list is applied at resolution time or connection time — if it's the former, DNS rebinding defenses may provide secondary bypass vectors. Confirm whether this affects HTTP/HTTPS repository URLs only, or also SSH-based migration with git:// or ssh:// schemes where DNS could still enable internal network reconnaissance. The worker node's network position is the real severity amplifier. Migration workers typically have elevated egress toward internal infrastructure — artifact registries, package mirrors, internal git hosts. If these run in AWS or GCP, SSRF to the metadata endpoint is a realistic path to instance credentials with permissions to read artifacts, trigger pipelines, or access secret stores. Repository migration is also transitional infrastructure that often runs on dependencies and service accounts that haven't been reviewed in months or years, creating forgotten credentials exposure that compounds the technical vulnerability.

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