CVE-2026-18369

This vulnerability exposes a recurring architectural failure: security-critical validation logic that relies on HTTP clients with defaults designed for general-purpose use rather than hostile environments, compounded by a feature shortcut that likely originated in testing infrastructure and never received a security review. The dual failure modes here—accepting IP address literals as DNS identifiers and following redirects without target validation—share a common root cause: developers using standard library HTTP behaviors that are helpful in normal contexts but dangerous when an attacker controls the target. The IP literal acceptance is the more revealing detail. This is almost certainly a convenience feature added for internal testing (validating that the ACME responder can reach itself during setup) that propagated to production without a threat model asking 'what if an external actor supplies this identifier?' The redirect-following component suggests someone used an HTTP client with auto-redirect enabled, which is the default in most libraries because it's the common case. Neither behavior is obviously wrong in isolation. Both become severe in an ACME validator where the server makes outbound requests to attacker-supplied destinations. For immediate defensive action: audit your ACME responder's HTTP client configuration. Disable automatic redirect following explicitly. Reject IP address literals in Host headers at the validation layer—not just in DNS resolution. If you deploy Dogtag, apply the available patch without delay. The InMemory backend disclosure mechanism is the second-order concern worth examining. The fact that response bodies leak only in certain backend configurations suggests incomplete threat modeling across deployment scenarios. Teams building ACME responders likely test against one backend and assume validation logic is backend-agnostic. This assumption failed here. The severity here is actually higher than it first appears: the combination of SSRF (requesting internal services) plus response exfiltration (getting those contents back) transforms a limited server-side issue into a data breach requiring customer notification. The deeper architectural question is what safe defaults HTTP clients used in validation contexts should enforce. The answer is: no redirect following, explicit rejection of IP literals in Host headers, connection timeouts under 5 seconds, and response body caps. Treat the HTTP client as a security boundary, not a utility. This abstraction should be validated through property-based testing that generates adversarial Host headers and URI targets. The protocol-layer question matters: RFC 8555 leaves redirect handling as a SHOULD and doesn't explicitly prohibit IP literals in Host headers—it's left to implementations. Every ACME responder independently re-implements this HTTP client behavior and will independently fail to secure it. The vulnerability debt compounds because some implementations will fix this within days, others will wait for RFC clarification that may never come, and some will never fix it because they're on deprecated branches. The systemic risk isn't one deployment's exposure—it's the distribution of remediation timelines across the ecosystem, where a 6-month lag at 20% of deployments means the vulnerability remains exploitable at scale long after the CVE is published.

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