When patches cannot be applied right away, teams should reduce attack surface with temporary mitigations. The article recommends disabling HTTP/2 support in Kong or lowering the HTTP/2 keepalive limit. That buys time while preserving service continuity. Mitigations should be paired with a rapid plan to deploy the fixed versions as soon as change windows allow.
What to do when patching is delayed for an HTTP/2 rapid reset issue
When you cannot patch immediately, treat the issue as an active exposure and narrow the attack path with temporary controls that reduce HTTP/2 abuse. The goal is to preserve availability while lowering request churn and resource exhaustion until the fixed release can be deployed. The right workaround is the one your team can verify quickly and roll back cleanly.
For environment-specific mitigations, focus on controls that directly change the attack surface rather than general hardening. If your reverse proxy or ingress stack can safely do it, disabling HTTP/2 is the bluntest option; if not, lowering keepalive or similar connection limits can reduce the cost of rapid stream resets while you keep the service online.
These mitigations are not equivalent to a fix. They buy time, but they also change client behaviour and may affect latency, multiplexing efficiency, or compatibility with downstream services. Teams should document the exact temporary setting, who approved it, and what condition will trigger restoration to normal HTTP/2 operation once patched builds are available.
How temporary mitigation should be operationalised
Temporary mitigation works best when it is treated as an explicit change, not an informal emergency tweak. Apply it in the smallest scope that covers the exposed path, confirm that the configuration actually took effect, and monitor for service degradation or unexpected client failures after the change lands.
If the issue affects a shared edge or gateway, coordinate the rollback path before making the change. That matters because the best interim control is often the one that can be reversed quickly once the patched version is ready, especially if the workaround shifts traffic patterns or removes HTTP/2 features that some clients depend on.
Where teams run multiple ingress layers, apply the mitigation at the layer that receives the untrusted traffic first. Doing so reduces the volume of reset-driven churn before it propagates into internal tiers, which is usually more effective than trying to absorb the load deeper in the stack.
When to restore HTTP/2 and remove the workaround
Restore normal HTTP/2 behaviour only after the fixed version is deployed and verified in the same path that was temporarily changed. A workaround should be considered complete only when you can prove that the patched software is live, the temporary control is no longer needed, and the service still meets its availability expectations.
Teams should also check whether the mitigation masked any capacity issues. If the service was already close to saturation, a rapid reset event can expose weak headroom even after patching, so it is worth validating request volume, connection handling, and error rates during the return-to-normal phase.
Risk and Threat Considerations
Rapid reset abuse can turn a protocol feature into a practical denial-of-service path by forcing servers or intermediaries to spend disproportionate effort on connection and stream handling. If patching is delayed, the main risk is not just exploitation, but uncontrolled resource consumption that can degrade service before defenders have time to change versions.
Failure mechanism: The attacker repeatedly opens and resets HTTP/2 streams at a rate that creates high per-request overhead, especially on shared gateways and edge components that terminate traffic for many clients.
Impact: Availability degrades first, then operational response becomes harder because the team is forced to choose between short-term service protection and protocol compatibility until the patched release is live.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Temporary protocol changes require controlled access and verified authorization to reduce exposure. |
| PR.DS-01 — Data-at-Rest Protection | Mitigations affect service handling and should preserve protected service data while traffic is constrained. | |
| DE.CM-01 — Networks and Network Services Monitored | Rapid reset abuse is visible through anomalous network and service telemetry. | |
| Recommendation — Restrict and verify who can change edge protocol settings and related access paths. Preserve confidentiality and integrity of protected data while applying interim traffic controls. Monitor edge and service telemetry for repeated stream-reset patterns and abnormal request churn. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | The issue is mitigated by changing network-facing protocol handling at the edge. |
| Recommendation — Harden and adjust internet-facing network services with reversible configuration changes. | ||
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | HTTP/2 transport handling sits within secure transmission and protocol enforcement decisions. |
| Recommendation — Apply secure transmission settings consistently while you deploy the fixed version. | ||
Practitioner Guidance
What to prioritise: Prioritise the control that reduces load fastest with the least operational blast radius. For most teams that means a reversible edge change, then rapid verification that the traffic path actually stopped accepting the abusive pattern.
Decision rule: If you can patch the exposed tier immediately, do that. If you cannot, use the temporary mitigation only long enough to bridge the change window, then remove it as soon as the fixed build is confirmed in production.
Practitioner takeaway: Treat the workaround as a bounded risk-reduction measure, not a substitute for remediation, and make sure the team knows exactly when the temporary control can be safely retired.
Related resources from NHI Mgmt Group
- How should API teams respond when an HTTP/2 rapid reset vulnerability is disclosed in their gateway stack?
- What breaks when teams assume they are safe after patching for a previous React security issue?
- How should security teams manage unsupported assets when patching is no longer possible?
- What should teams do immediately after patching an exploited Magento zero-day?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
