CVE-2023-54365: 
Go Schwachstellenanalyse und -minderung

CVE-2023-54365 is a denial-of-service vulnerability in Traefik's HTTP/2 request handling, inherited from the Go standard library's HTTP/2 implementation via the 'Rapid Reset' technique (related to CVE-2023-44487 and CVE-2023-39325). It affects Traefik versions prior to 2.10.5 and 3.0.0-beta1 through 3.0.0-beta3, as well as Go versions prior to 1.20.10 and 1.21.0–1.21.2. Red Hat OpenShift AI (RHOAI) is also listed as an affected product. The CVE was published on June 23, 2026, with a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.7 (High) (Github Advisory, Traefik Advisory, Red Hat Bugzilla).

The root cause is uncontrolled resource consumption (CWE-400) and allocation of resources without limits or throttling (CWE-770) in the Go standard library's golang.org/x/net HTTP/2 implementation. The vulnerability is not caused by Traefik-specific code; rather, Traefik inherited it by depending on a vulnerable version of Go's HTTP/2 module (Red Hat CSAF). An unauthenticated remote attacker exploits the 'Rapid Reset' technique by rapidly opening and immediately canceling HTTP/2 streams (via RST_STREAM frames), causing the server to allocate resources for each stream without adequate throttling, ultimately exhausting server capacity. No authentication or user interaction is required, and the attack can be automated at scale (Traefik Advisory, Github Advisory).

Successful exploitation results in a denial of service, rendering the Traefik reverse proxy/load balancer unavailable to legitimate users. There is no impact on confidentiality or integrity — the attack is purely an availability concern. Because Traefik commonly serves as an ingress controller in containerized and cloud-native environments, its unavailability can cascade to all backend services it proxies, potentially causing broad service outages (Red Hat CSAF, Github Advisory).

1. Reconnaissance: Identify internet-facing Traefik instances running versions prior to 2.10.5 (v2 branch) or 3.0.0-beta4 (v3 branch) using tools like Shodan, Censys, or by inspecting HTTP response headers (e.g., Server: Traefik).
2. Establish HTTP/2 connection: Initiate a TLS connection to the target Traefik instance and negotiate HTTP/2 using ALPN (Application-Layer Protocol Negotiation).
3. Rapid stream creation: Using an HTTP/2 client or custom tooling, rapidly open a large number of HTTP/2 streams (HEADERS frames) in quick succession without waiting for server responses.
4. Immediate stream cancellation: For each opened stream, immediately send an RST_STREAM frame to cancel it, preventing the server from completing request processing while still consuming server-side resources.
5. Resource exhaustion: Repeat steps 3–4 at high volume to exhaust the server's goroutine pool, memory, or CPU, causing Traefik to become unresponsive to legitimate traffic (Traefik Advisory, Github Advisory).

• Network: Sudden spike in HTTP/2 connections from one or a small number of source IPs; high volume of RST_STREAM frames observed in network captures on port 443 or 80; abnormally high rate of short-lived HTTP/2 streams.
• Logs: Traefik access logs showing a flood of requests with immediate resets or errors (e.g., stream reset by peer, connection reset); unusually high request rates from specific clients with no corresponding successful responses.
• Process/System: Elevated CPU and memory usage on the Traefik process; goroutine count growing unboundedly (visible via Traefik's /metrics or /debug/pprof endpoints if exposed); system-level resource exhaustion indicators such as OOM events.
• Availability: Legitimate users experiencing timeouts or connection refused errors when accessing services proxied by Traefik during the attack window (Red Hat CSAF).

The primary remediation is to upgrade Traefik to version 2.10.5 (v2 branch) or 3.0.0-beta4 (v3 branch), which include updated Go HTTP/2 dependencies containing the upstream fix. No configuration-based workaround is available from the Traefik project. As a supplementary defense-in-depth measure, consider implementing rate limiting and connection throttling at the network or load balancer level to reduce the impact of HTTP/2 stream exhaustion attacks. Red Hat OpenShift AI (RHOAI) users should apply available updates to the odh-rhel9-operator and rhai-cli-rhel9 components (Traefik Advisory, Red Hat CSAF).