CVE-2026-58189 is a redirect-limit bypass in Apache Traffic Server (ATS) that allows a malicious or compromised plugin to reset the internal retry counter, defeating the protection against redirect loops. The practical impact is SSRF amplification: an attacker who can trigger redirects through ATS while a plugin resets the counter doesn't just bypass a limit — they weaponize ATS's position as a proxy to scan internal services, pivot to internal-only applications, or conduct reconnaissance that would otherwise require direct network access.
The vulnerability affects versions 8.x through 10.x. Patches are available in 9.2.15 and 10.1.4. The version spread is analytically significant — the same architectural flaw existed across major version ranges, indicating this was a design decision, not an implementation oversight. ATS's plugin API was intentionally designed to allow plugins to observe and influence connection lifecycle state, including retry logic. The retry counter exists because legitimate plugins need custom retry behavior for backpressure handling and connection health monitoring.
What you should do: upgrade to 9.2.15 or 10.1.4 immediately. That's the baseline. But understand what the patch likely does and doesn't do. The fix probably adds compensating controls — rate limiting on reset calls, additional state flags, or audit logging — rather than removing the reset capability entirely. Removing it would break legitimate plugins that depend on custom retry logic.
The deeper problem this CVE exposes: the patch protects against external attackers exploiting ATS, but it does nothing about a compromised or malicious plugin. If you're running any third-party ATS plugins, audit them specifically for redirect and retry manipulation. A plugin that can reset the retry counter can turn your ATS instance into an SSRF amplifier against your internal infrastructure. The vulnerability is in the extension point — the patch closes one path through it, but the extension point itself remains.
For architecture decisions: treat this as evidence that plugin extension points modifying security-critical state represent a trust-model violation, not a patchable bug. The pattern of similar CVEs across Nginx, HAProxy, and Squid suggests this is an inherent tension in extensible proxy architectures. If you're evaluating proxy solutions, factor this into your threat model — an extensible proxy is only as secure as the least-aware plugin author.