Rapid Reset denial of service affects Siemens products and HTTP/2 implementations

The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.

• HTTP/2 version 2.0 is marked affected.
• Siemens: the record lists SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP firmware, SIMATIC S7-1500 CPU 1518-4 PN/DP MFP firmware, SIPLUS S7-1500 CPU 1518-4 PN/DP MFP firmware, RUGGEDCOM APE1808 firmware, SINEC NMS, SINEC INS, and ST7 SCADACONNECT. Additional affected data uses the boundaries 0 < * for RUGGEDCOM APE1808, V3.1.5 < * for the listed CPU lines, and 0 < V3.0 for SINEC NMS. SINEC INS 1.0 and its listed service-pack variants are marked affected. The boundary notation is preserved because the supplied evidence does not provide a complete vendor interpretation for each line.
• Envoy: 1.24.10, 1.25.9, 1.26.4, and 1.27.0 are marked affected.
• F5 BIG-IP: the record marks Access Policy Manager, Advanced Firewall Manager, Advanced Web Application Firewall, Analytics, Application Acceleration Manager, Application Security Manager, Application Visibility and Reporting, Carrier-Grade NAT, DDoS Hybrid Defender, Domain Name System, Fraud Protection Service, Global Traffic Manager, Link Controller, and Local Traffic Manager as affected. These entries include unspecified version branches and an explicit 17.1.0 entry.
• nghttp2, Netty, Eclipse Jetty, Caddy, Go, Go http2, and Go networking are marked affected, but the normalized record does not provide complete version boundaries for these entries.

HTTP/2 allows a client to cancel an individual stream with an RST_STREAM frame without closing the connection. In a Rapid Reset attack, the client sends a request and immediately sends RST_STREAM; the server or reverse proxy may already have allocated stream state, parsed headers, decompressed headers, mapped the URL, or forwarded the request to a backend before cancellation is processed. Repeating this quickly allows new streams to be created without exceeding the normal limit on concurrently open streams, while server-side work accumulates and can greatly exceed the attacker’s cost. Exploitation requires a service that accepts HTTP/2 from an untrusted network; the record indicates that authentication and user interaction are not required. The implementation details and resource cost vary by product, so the record does not establish one identical code path across all affected products.

The issue is remotely reachable over HTTP/2, requires no authentication, requires no user interaction, and has low attack complexity. The record states that the technique was exploited in the wild from August through October 2023. It also marks the vulnerability as known exploited and indicates that public exploit material exists. The available evidence does not identify a specific campaign, victim, or threat group. The documented result is denial of service and resource consumption, not data access or data modification.

• The primary effect is loss of availability because the server processes many requests that are canceled and consumes resources for each stream.
• The HTTP/2 connection can remain open while the attacker repeatedly creates and resets streams, allowing one connection to generate more work than the normal concurrent-open-stream limit would suggest.
• Realistic outcomes include high CPU or memory use, request backlogs, increased latency, service errors, and connection termination; with a reverse proxy, the load may reach backend systems.
• The record describes no confidentiality or integrity impact and does not establish privilege escalation, code execution, or data access.
• The outcome depends on whether the product accepts HTTP/2 from an untrusted network, how it processes canceled requests, and whether it can apply reset limits or terminate abusive connections.

• The attack can increase CPU, memory use, active work, and request queues on a server or reverse proxy.
• Web services, APIs, gateways, proxies, and management interfaces may experience latency, failed requests, connection termination, or loss of availability.
• When an HTTP/2 component forwards a request to a backend before processing cancellation, discarded work can propagate into downstream services and degrade multiple layers.
• For affected industrial products, loss of availability for management or monitoring interfaces is possible when those interfaces accept HTTP/2 from an untrusted network.
• The evidence does not establish data disclosure, data modification, privilege escalation, or a specific compromise scenario.

1. Update each product or dependency using the vendor’s official security release, prioritizing public HTTP/2 endpoints and edge devices or gateways. Do not use a fix for one project to infer that a parallel branch or product is safe.
2. For nghttp2, release v1.57.0 explicitly states that it fixes the issue. For Envoy, Netty, Go, Caddy, Eclipse Jetty, F5, and Siemens, use the vendor update that contains Rapid Reset protection; the supplied record does not establish an exact fixed release for every branch.
3. If updating is not immediately possible, place the service behind DDoS mitigation or an HTTP/2-aware proxy that can detect and limit abnormal reset behavior, and close abusive connections where the vendor supports that control. Treat this as temporary mitigation, not a replacement for updating.
4. Reduce exposure of affected HTTP/2 listeners to untrusted networks. If no vendor-supported patch or mitigation is available, consider removing the product from untrusted traffic in accordance with vendor guidance.
5. After updating, verify the actual binary, image, firmware, and packaged dependency versions, then perform controlled HTTP/2 load validation to confirm that reset limits do not disrupt legitimate requests.

1. Inventory every web server, reverse proxy, gateway, load balancer, industrial management interface, and library that accepts HTTP/2, including transitive dependencies.
2. Compare vendors, products, and release branches with the affected list; do not treat a fix in one library or branch as evidence that parallel branches are safe.
3. Review HTTP/2 telemetry for unusual bursts of client-sent RST_STREAM frames, repeated create-then-cancel patterns, high stream churn, or connections closed because of abusive behavior.
4. Correlate stream-reset bursts with CPU, memory, request queues, latency, 5xx errors, and work generated at backends. These are operational signals to investigate, not standalone IOCs.
5. The supplied evidence does not establish one product-independent IOC. The absence of these signals does not prove that a system is safe.