Rapid Reset sorted agency websites into three groups, and one of them had no owner

The week

For several weeks in late summer 2023, some of the largest companies on the internet were fighting an attack that almost nobody outside them knew about. When they finally described it, the numbers were startling, and so was the simplicity of the trick behind it.

On October 10, 2023, Google, Cloudflare and Amazon Web Services jointly disclosed a vulnerability in the HTTP/2 protocol, tracked as CVE-2023-44487 and known as Rapid Reset. A protocol is an agreed set of rules for how two computers talk. HTTP/2 is a widely used version of the rules your browser follows when it asks a website for a page. A CVE number is the industry’s catalog reference for a publicly known security flaw, so that everyone can be sure they are discussing the same one.

HTTP/2 lets a browser open many “streams,” separate requests running side by side over one connection. It also lets the browser cancel a stream it no longer needs. Rapid Reset abused that courtesy. By opening streams and immediately cancelling them, over and over, an attacker could force servers to do large amounts of work with little effort, thousands of times a second.

Cloudflare’s technical write-up spelled out why the usual safeguard failed. Servers cap how many streams a client may have open at once. A stream that has been cancelled no longer counts toward that cap, so the attacker can open the next one immediately. The cap limits how many requests are in flight. It does nothing to limit how many requests are sent.

The result was a new kind of distributed denial-of-service attack, usually shortened to DDoS. A DDoS attack does not steal anything. It floods a service with so much junk traffic, from so many machines at once, that real users cannot get through. The providers said the attacks using this technique were far larger than any they had previously seen, and that they had been mitigating them since late August.

The published figures were striking. Google said the largest attack it saw peaked at 398 million requests per second, about seven and a half times its previous record of 46 million. That attack lasted two minutes. Google said it generated more requests than Wikipedia recorded in article views during the whole of September 2023. Cloudflare reported a peak just above 201 million requests per second, nearly three times its own previous record.

The size of the attacking force was the more unsettling number. Cloudflare said the attacks came from a botnet of roughly 20,000 machines, small by the standards of the day. Botnets of hundreds of thousands or millions of devices already existed. A technique that let a modest botnet set records implied what a larger one might do with it.

Even the giants felt it. Cloudflare said that in the first wave about 1 percent of requests through its network returned errors, with peaks near 12 percent for a few seconds during an attack on August 29. While it worked on a fix, it lowered the number of streams each connection could open. That broke some legitimate clients, such as image-heavy pages that request many files at once, and it raised the limit again.

Because the flaw lay in how implementations handled a standard protocol feature, it was not confined to one product. It affected many web servers, proxies and load balancers, the equipment and software that receive web traffic and pass it along. Vendors released patches and configuration guidance over the following days and weeks. Google rated the flaw high severity, 7.5 on the industry’s standard 10-point scale.

Amazon said its own infrastructure already had protections against floods of web requests and that it had added more. Its advice to customers running their own HTTP/2 servers was blunt: check with the server vendor about exposure and install the latest patches. Cloudflare’s advice was to place a denial-of-service mitigation service in front of any web-facing server while vendors caught up.

The Cybersecurity and Infrastructure Security Agency, CISA, the federal agency that coordinates civilian cyber defense, published guidance urging organizations to apply updates and mitigations. It said the flaw had been exploited in the wild from August through October 2023.

The same day, CISA added the flaw to its Known Exploited Vulnerabilities catalog. Under Binding Operational Directive 22-01, federal civilian agencies must fix catalog entries by a set date. For Rapid Reset the deadline was October 31, 2023. The required action was to apply vendor mitigations, follow the directive’s guidance for cloud services, or stop using the product if no mitigation was available.

The disclosure posed an awkward question for government agencies. The giants had protected themselves, and their customers, before anyone heard the name Rapid Reset. Which agency services were sheltered behind that kind of protection, and which were standing out in the open?

Denial-of-service attacks against government websites were familiar by 2023. Politically motivated groups had knocked state government and airport sites offline for hours in 2022. Those outages rarely touched sensitive data, but they were embarrassing and disruptive, and they landed exactly when residents were trying to find information or get something done.

Most of those earlier floods were measured in raw volume, the quantity of data aimed at a target. Rapid Reset belonged to a different family. It attacked the application layer, where each request forces a server to do work: read headers, check rules, look up a page. A server can be swamped by requests long before its network link fills up, which is why request rates, not bandwidth, were the headline figures that October.

Rapid Reset changed how much disruption a modest set of attacking machines could cause. The providers who disclosed it had absorbed the attacks before anyone outside knew. The useful question for an agency CIO was therefore narrower than whether the agency was vulnerable: which of its public services sat behind that kind of protection?

Every internet-facing service falls into one of three groups, and the groups are exhaustive: services fronted by a large edge provider, services the agency hosts and protects itself, and services nobody can account for. Each group needs a different decision, and the moving parts come first.

From web address to origin server

When a resident types an agency’s web address, a chain of systems springs into action. The domain name system, or DNS, turns the friendly name into a numeric address. The request then travels to whatever machine sits at that address.

For a self-hosted service, that machine is the agency’s own: a web server in an agency data center, or a virtual machine the agency rents in a commercial cloud and runs itself. The server that actually holds the application is called the origin. Often a load balancer sits in front of it, spreading incoming requests across several servers so that none is overwhelmed.

For a service fronted by an edge provider, the request first reaches a vast, shared network run by a company such as a content delivery network or a large cloud provider. “Edge” refers to the outer rim of the internet, close to users. These networks have points of presence in many cities and enormous spare capacity. They answer what they can themselves, filter out junk, and pass legitimate requests back to the agency’s origin. The arrangement works like a large, well-staffed security lobby in front of a small office: visitors pass through the lobby first, and the office only sees the ones who belong.

A patch is a software update that fixes a flaw. A configuration change alters settings rather than code, for instance limiting how many streams a single connection may open. For Rapid Reset, both approaches were used.

Finally, an API, or application programming interface, is a doorway built for software rather than people. When a mobile app shows a resident their case status, it is calling the agency’s API. APIs speak the same web protocols as websites, so they were exposed to Rapid Reset too, even though no human ever visits them in a browser.

Why HTTP/2 made the trick cheap

The older HTTP/1.1 sends one request at a time over each connection and waits for the answer. A client that wants many things at once opens several connections, and servers limit how many each client may hold. HTTP/2 replaced that with multiplexing: many streams over one connection, interleaved. Servers protect themselves by capping concurrent streams per connection. Cloudflare’s cap, for example, was 100.

Rapid Reset exploited the gap between that cap and the work behind it. The attacker sends a request, then a cancellation, then the next request. By the time the cancellation arrives, the server has already parsed the request and may have passed it to a back-end application. The attacker’s cost per request is a few bytes. The server’s cost is real processing, repeated as fast as the network allows.

That asymmetry explains the botnet arithmetic. Cloudflare attributed its record to about 20,000 machines. Under the old rules, the number of requests a machine could send was limited by waiting for answers. With waiting removed, each machine became far more productive, and the limiting factor moved to the defender’s capacity to process.

Where HTTP/2 actually ends

A detail that confused many teams that October was where the vulnerable conversation took place. The flaw lives in whatever software accepts HTTP/2 connections from the public. For a site behind an edge provider, that is usually the provider’s software. For a self-hosted site, it may be a load balancer, a reverse proxy or the web server itself. Many organizations terminate HTTP/2 at the load balancer and speak the older protocol to the servers behind it.

The question “are we vulnerable” therefore became “which component speaks HTTP/2 to the internet, and whose code is it.” The answer could be a cloud load balancer the provider patches, an appliance whose firmware the agency must update, or open-source software a contractor installed years ago. Each answer has a different owner and a different patching path.

Behind a large edge provider

Agencies that put public websites behind a content delivery network or a cloud load balancer with denial-of-service protection benefited without lifting a finger. The providers patched their own infrastructure and tuned defenses weeks before disclosure. Few arguments for shared infrastructure are clearer: capacity and engineering at a scale no single agency can build.

What the edge does during an attack

An edge network defends in layers. It answers requests for cached content, such as images and static pages, without troubling the origin at all. It drops traffic that breaks protocol rules, which is where the Rapid Reset fixes landed. It applies rate limits and bot rules to what remains. It can also challenge suspicious clients with a test that a browser passes and a simple script fails.

The weak point is dynamic content. A login page, a search box or an eligibility check cannot be served from a cache, because the answer depends on the request. Every one of those requests that passes the filters reaches the origin. An attacker who targets the most expensive dynamic page, with traffic that looks plausible, can still overwhelm an origin behind a well-run edge network. The edge reduces the problem. Tuning finishes the job.

Cloudflare’s own account shows the trade-offs. When it cut the number of streams per connection to blunt the attack, some legitimate pages broke. Every protective setting has a cost in false positives, and the right threshold for a press release page is wrong for a benefits application. Agencies that leave every setting at the default inherit choices made for an average customer.

Seeing what the provider sees

Rented protection can also hide problems from the renter. Cloudflare later said that the errors in its first wave did not show up in customers’ dashboards, because they were logged by an internal component. Some customers’ visitors were getting errors that the customers themselves could not see. An agency that relies on the provider’s console alone may learn about degraded service from residents.

Two habits close that gap. The first is independent monitoring that requests key pages from outside, from several locations, and alerts when responses slow or fail. The second is sending the provider’s logs to the agency’s own security operations team, so that attack traffic, rule changes and errors appear alongside everything else the team watches. Both are inexpensive next to the edge contract itself.

Protection still depends on configuration. If an origin server accepts traffic from anywhere, an attacker who discovers its address can go around the edge entirely, like a side door onto the street that bypasses the lobby. Origin addresses leak through old DNS records, certificate transparency logs and email headers. Certificate transparency logs are public records of the digital certificates that make websites secure, and they can reveal the names and sometimes the addresses of servers an agency would rather keep private.

Three checks matter. Origins should accept connections only from the provider’s published address ranges or through an authenticated tunnel, a private, verified connection between the provider and the agency. Rate limits and bot rules should be set per application, because a benefits login page and a static press page need different thresholds. And the agency should have a tested way to reach the provider’s response team during an attack, with the account details and escalation numbers held by the operations center, not by one engineer.

Locking down the origin has its own operational demands. Providers publish the address ranges their networks use, and those ranges change. An allow list maintained by hand drifts out of date, and a stale list either blocks the provider or lets others in. Authenticated tunnels avoid the problem, because the origin makes an outbound connection to the provider and accepts nothing inbound. They do require the origin team to run and monitor one more component.

Contracts deserve a look too. Denial-of-service protection may be priced as a premium tier, and some agreements cap mitigation or charge for traffic during an attack. A county motor vehicles department could discover mid-attack that its plan covered only basic filtering, or receive a large bill afterward for the junk traffic it was forced to absorb. The procurement file should state which tier each critical service is on and what happens to the bill when an attack arrives.

Federal, state and local differences

The rules around edge services differ by level of government. Federal civilian agencies generally need cloud services authorized under FedRAMP. They must also fit edge services into the Trusted Internet Connections program, whose third version allows more flexible, cloud-based designs than the original physical gateways. They had the KEV deadline of October 31 for any affected system they ran.

State agencies often buy through statewide contracts negotiated by the state chief information officer, and many share a central network and hosting service. A shared state service can put dozens of agencies behind one edge contract at once. It can also mean a single team holds the escalation path for all of them, and the contract tier is set for the average agency.

Counties, cities and school districts vary widely. Many run their main sites on a website vendor’s hosted platform, and the protection in front of it is whatever the vendor chose. Courts and elected offices such as clerks, treasurers and election officials often run their own systems, separate from the general government’s IT. A county’s three groups may therefore sit across several independent organizations, each with its own contracts.

Concentration as a counter-argument

The strongest case against relying on edge providers is concentration. When many agencies sit behind one provider, a fault at that provider takes them all down at once. In June 2021 an outage at the content delivery company Fastly briefly knocked many major websites offline, including the UK government’s main site. An agency that fronts everything with one provider has swapped one kind of outage risk for another.

The swap is usually worth making, but it should be made knowingly. Provider outages tend to be short and widely noticed, and the provider has every incentive to fix them fast. A self-hosted service under a large attack may stay down for as long as the attacker likes. For a handful of critical services, an agency can reduce the concentration risk with a documented way to switch the name to a backup path, tested before it is needed.

Self-hosted, and making the choice explicit

Many agency applications are still served from agency data centers, or from cloud virtual machines running the agency’s own web servers and load balancers. These needed patches or configuration changes, and vendors released them at different speeds. Some network appliances needed firmware updates that required maintenance windows, scheduled periods when a system can safely be taken down. Some older platforms were out of support and received nothing.

Three ways to close the hole

Self-hosting agencies had three broad options that October. The first was the vendor patch, which usually added limits on how many cancellations a connection could send before the server closed it. The second was configuration: lowering stream limits or tightening connection timeouts, where the software allowed it. The third was to switch HTTP/2 off on the exposed component and fall back to HTTP/1.1, which Cloudflare noted could not be abused this way.

Each option had costs. Patches on network appliances meant maintenance windows and change approvals, and a failed firmware update on a load balancer is its own outage. Tighter limits risked the same false positives Cloudflare saw. Turning HTTP/2 off slowed pages that load many files and could break applications built to expect it. For an out-of-support platform, the realistic option was often to place a supported reverse proxy or a cloud edge service in front of it, which is a small architecture project, not a patch.

Federal civilian agencies had the added discipline of the KEV deadline. Three weeks is short for a change that touches every load balancer. Agencies that already had an inventory of internet-facing components could plan the work in days. Those without one spent most of the window finding the systems, which left little time to change them safely.

Detection also differs for self-hosted services. A Rapid Reset attack does not look like a classic flood on a network graph. Bandwidth may stay modest while processor load and back-end queues spike. The telltale sign is at the protocol level: an unusual ratio of cancelled streams to completed ones on each connection. Teams that collected only bandwidth and uptime figures had little to go on, and the fix for that is logging at the load balancer or proxy that terminates client connections.

Even fully patched, a self-hosted service lacks the capacity to absorb a very large attack. Patching closes the specific trick without adding capacity, and a determined attacker with enough machines can still flood it by other means.

For services residents depend on, such as benefits portals, licensing, tax filing, court records and emergency information, the choice should be explicit. Either the agency fronts the service with an edge provider and accepts the dependency and cost, or it accepts that the service may go down during a large attack. In the second case it plans for that, for example with phone and in-person fallbacks and authority to extend filing deadlines. Both can be reasonable. Making the choice by default is not.

The decision, its owner and the date it was last reviewed belong in the system’s security documentation, where an auditor or a new CIO can find it. A short paragraph is enough: this service is self-hosted, we accept the risk of outage during a large attack, here is the fallback, and here is who signed off.

The capacity question deserves numbers that the agency can actually obtain. One is how much traffic the agency’s internet connection can carry, and whether the upstream carrier offers filtering. Another is how many requests per second each critical application can serve before response times degrade. Load testing answers the second, and many agencies have never run it against their public services. Without those figures, “we accept the risk” is a guess, not a decision.

Regulated data adds constraints. Services that handle criminal justice information, federal tax information or protected health information may restrict which providers can terminate encrypted traffic and where. “Terminating” encrypted traffic means unlocking it to inspect it, which an edge provider must usually do to filter attacks. Those constraints can usually be met, for instance with a provider authorized under FedRAMP, the federal program that assesses the security of cloud services, or with configurations that keep decryption inside the agency. They need to be worked out with the security and compliance owners before an incident, because an outage is the wrong time to negotiate a data handling question.

Each regime sets its own conditions. Criminal justice information falls under the FBI’s CJIS Security Policy, which governs who may access unencrypted data and under what agreements. Federal tax information shared with state agencies is governed by IRS Publication 1075. Protected health information held by a state health agency or public hospital falls under HIPAA, which would generally require a business associate agreement with a provider that decrypts it. An edge service that only passes encrypted traffic through, without decrypting it, raises fewer questions but filters less.

The services nobody can account for

Every internet-wide vulnerability exposes forgotten services. Rapid Reset affected any HTTP/2 endpoint: APIs behind mobile apps, partner integrations, vendor-hosted portals carrying the agency’s name, and microsites for programs that ended years ago. An endpoint is any address on the internet where a service answers requests.

Agencies with a complete inventory of internet-facing services could assess their exposure within a day. Others learned through outages or from outside scanning, which is to say they learned from residents, reporters or researchers rather than from their own records.

Building the inventory

An external inventory is assembled from several sources, because no single one is complete. The agency’s own DNS zones list the names it controls. Domain registrar records list domains it has registered, including forgotten ones. Certificate transparency logs show certificates issued for its names, sometimes by vendors it no longer remembers. Cloud account listings show public addresses and load balancers. Procurement and contract records reveal vendor-hosted services that carry the agency’s name but none of its infrastructure.

Each record then needs two owners. A business owner decides whether the service should exist and how much an outage matters. A technical owner knows how it is hosted and can change it. Services without a business owner are candidates for retirement. Services without a technical owner are the ones that will not be patched when the next flaw arrives.

Interfaces need their own pass. Mobile apps, partner integrations and data feeds often run through an API gateway that a different team manages, and their addresses rarely appear on the public website. A catalog of published interfaces, with the gateway as the single public entrance, makes them visible. Interfaces that bypass the gateway are the ones most likely to be missing from every list.

Temporary programs are a common source of strays. Emergency relief programs in 2020 and 2021 led many agencies to stand up sites quickly, often through vendors and sometimes on new domains. Some outlived the programs. Each one is a candidate for the third group until someone confirms its status.

Retirement needs its own procedure. Switching off a forgotten site is good practice, but letting its domain lapse can be worse than leaving it running. Someone else may register the name and serve content that residents trust because the address looks official. A retired service should redirect to a current page, and the agency should keep the domain registered.

The remedy is an external attack surface inventory, continuously updated, listing domains, certificates, address ranges and applications, with a named owner and an availability tier for each. “Attack surface” is the security term for everything an outsider could reach and try to break. An availability tier says how much it matters if the service goes down: an emergency information site and a decade-old event page do not deserve the same attention.

Federal civilian agencies could draw on CISA’s scanning services, and CISA offered vulnerability scanning to state and local governments as well. Vendor-hosted services belong on the list, because a resident who cannot reach a portal blames the agency whose name is on it. A useful contract clause requires vendors to disclose the protection in front of any service they host for the agency.

The clause can go further at little cost. It can require the vendor to notify the agency when a service carrying its name is under attack or degraded, within a stated time. It can require the vendor to confirm, after any internet-wide flaw, whether the agency’s services were affected and when they were fixed. And it can give the agency a named contact for incidents. Without those terms, the agency learns about its vendor’s outage the same way residents do.

The inventory is what makes the first two groups manageable. Without it, an agency cannot say which services are behind the edge, which are self-hosted, or how many sit in neither column. A simple quarterly measure tells leadership whether the third group is shrinking: the number of public endpoints with no named owner.

The inventory pays for itself beyond denial-of-service. The same list answers the first question in a ransomware investigation, a phishing campaign that imitates an agency site, or an audit of encryption settings. Agencies that built it for Rapid Reset found it useful for every internet-wide flaw that followed. Agencies that answered Rapid Reset with a one-off spreadsheet had to rebuild the spreadsheet each time.

Three county services on the morning of an attack

Suppose a large denial-of-service campaign turns toward government websites one morning, and take a county government in its path. The county runs dozens of public services. Three of them tell the story.

The first is the county’s main website, where residents find office hours, emergency notices and meeting agendas. A few years earlier the county put it behind a content delivery network. On the morning of the attack, the provider’s network soaks up the junk traffic. Residents notice nothing. The only work for county staff is a call from the operations center to the provider, using the escalation number kept on the center’s wall. The call confirms that the protection is active and tightens the rate limits on the site’s search page. Because the origin server only accepts traffic from the provider, the attacker has no side door to try.

The second is the property tax payment portal, which the county hosts in its own data center. It was patched promptly when the vendor’s fix arrived. But patched or not, it was never built to absorb a flood of this size, and it slows to a crawl and then stops answering. Here the difference between a decision and a default becomes visible. Because the county had written down, a year earlier, that it accepted this risk for the portal, it also had a plan. The treasurer’s office already held authority to extend the payment deadline by a few days in the event of an outage. The call center had a script, and residents could still pay by phone and in person. The outage is a nuisance, announced calmly on the main website, which is still up. Had nobody made that decision, the same outage would have arrived as a surprise on a deadline day. It would have brought angry residents, confused staff and a local news story about government that cannot keep its websites running.

The third is a microsite for a housing grant program that ended three years ago. A former vendor built it, the domain still renews automatically, and nobody at the county remembers it exists. It goes down too, and since no one is watching it, no one notices until a reporter asks why a county site is displaying an error. Worse, during the investigation the security team discovers it is running out-of-date software that would have been vulnerable to far more than a denial-of-service attack. It should have been switched off years earlier, and an inventory with a named owner would have caught it.

The county’s after-action review is where the morning pays off. The main website’s settings are recorded as having worked, and the search page’s new rate limit is made permanent. The tax portal’s outage is logged with its duration and call volumes. That record gives the county’s budget office a real figure to weigh against the cost of moving the portal behind the edge provider. The microsite is retired, its domain kept and redirected, and the inventory gains a line it should always have had.

Neither the skill of the county’s engineers on the day nor the cleverness of the attack decided these outcomes. Choices made, or not made, months earlier did: to put one service behind an edge provider, to accept and plan for the risk on another, and to lose track of the third. The three-group view is therefore a management tool rather than a technical one. Each group corresponds to a decision a leader can see, question and own.

The cost of an outage that steals nothing

Denial-of-service is more than a nuisance, even though no records are stolen and services usually come back. The costs are real and land on the people agencies exist to serve. A benefits portal that goes down on the last day of a filing window shifts burden onto residents and call centers. An emergency information site that fails during a storm is a public safety problem. A licensing system that is unavailable for a day delays businesses and generates complaints to elected officials.

There is also a trust dimension. Politically motivated attacks are designed to make government look incapable. Even a short outage, timed around an election or a controversial decision, can become a story about competence. Officials who can say, calmly and quickly, which services were protected and what the fallback was for the rest are in a strong position. Those discovering their own estate in real time are not.

Finally, there is money. Edge protection costs something, outages cost something, and unknown services cost something when they fail. The three-group view turns a vague worry into a set of explicit trade-offs that a budget office can weigh.

Deadlines set in law

Fallbacks often depend on legal authority that has to exist before the outage. Some filing deadlines are set by statute or court rule, and an agency head cannot simply extend them. Others can be extended administratively, or by an emergency declaration. Agencies should establish with counsel, in advance, which deadlines their critical services support and who can move each one. The answer determines whether an outage on a deadline day is an inconvenience or a legal problem.

The case for putting this lower on the list

A reasonable security leader might rank denial-of-service below ransomware, account takeover and data theft. Those threats destroy or expose data, and denial-of-service usually does neither. With a fixed budget, that ranking is defensible. The three-group exercise survives it because it is cheap and serves other purposes. It needs an inventory, a few configuration checks and some written decisions, not a new platform. Most of the work also strengthens the agency against the threats ranked above it.

What the prepared agencies had in common

A well-prepared agency can produce, within a day of any new internet-wide flaw, a list of its public services sorted into the three groups. For group one, it knows the origins are locked down and the escalation path works. For group two, it has a documented decision and a tested fallback for each resident-facing service. For group three, it has a number, and that number falls every quarter.

The failures follow a pattern. Agencies assume that buying edge protection solves the problem, while leaving origin servers open to the whole internet. They hold the provider’s emergency contact in one engineer’s inbox. They discover during an attack that their contract tier does not include the protection they thought it did. They leave vendor-hosted portals off the inventory because someone else runs them. And they let self-hosted services drift into an unexamined default, where nobody has decided whether an outage is acceptable or what residents should do if one happens.

Prepared agencies also measured. Useful figures include the time taken to sort all public services into the three groups after a new flaw, and the share of resident-facing services with a written decision and a tested fallback. Another is the result of a periodic test that tries to reach each origin directly, bypassing the edge. A tabletop exercise once a year, built around a large attack on a deadline day, shows whether the escalation numbers, the call center scripts and the deadline authority work together.

A subtler failure is treating each new vulnerability as a fresh emergency rather than a test of a standing process. The agencies that coped best with Rapid Reset were those that already knew what they had, whatever the talent of their engineers.

What to ask the CIO this quarter

• Can we list every public website, API and portal that carries our name, including ones vendors run for us, and say whether each is behind an edge provider, hosted by us, or unknown?
• For services behind an edge provider, can anyone reach the origin server directly, and who holds the provider’s emergency contacts?
• Which protection tier are we paying for, and what happens to our bill during a large attack?
• For each self-hosted service residents depend on, who decided we accept the risk of outage, and what is the fallback?
• How many public endpoints have no named owner today, and was that number lower or higher last quarter?

With hindsight

Rapid Reset was patched widely within weeks. That was a real achievement, and it reflected the coordinated way the large providers disclosed the flaw alongside fixes and guidance. Google described sharing intelligence and mitigation methods with other cloud providers and with the maintainers of HTTP/2 software while the attacks were under way.

The federal catalog entry was unusual in form. CISA listed the vendor simply as the IETF, the body that sets internet standards, and the product as HTTP/2. Its note said the flaw affected a common protocol used by many different products. For agency teams, that meant the required action reached every product that implemented the protocol, not one vendor’s line.

The broader threat did not shrink. Attackers went on to build larger botnets from compromised devices. A botnet is a large collection of hijacked computers, cameras, routers and other internet-connected gadgets, controlled remotely and pointed at a target all at once. Large providers reported successive records for volumetric attacks through 2024 and 2025, meaning attacks measured by the sheer quantity of data thrown at a target rather than by clever abuse of a protocol.

The protocol itself kept returning to the headlines. In April 2024 the CERT Coordination Center published a note on HTTP/2 CONTINUATION frames, reported by the researcher Bartek Nowotarski. Many implementations placed no limit on how many of these header fragments a client could send. An attacker could exhaust a server’s memory or processor time, and the note listed separate flaws in widely used software, including Node.js, Envoy, Go’s web library and the Apache web server.

In August 2025 researchers at Tel Aviv University disclosed a related HTTP/2 weakness, which they called MadeYouReset. Rapid Reset had relied on cancellations sent by the client. MadeYouReset tricked the server into cancelling streams itself, using malformed frames. Many servers kept working on those requests after the protocol treated them as closed, so the concurrency cap again failed to bind.

The two disclosures showed the protocol’s stream handling remained a source of denial-of-service risk. The same courtesy that Rapid Reset had abused, the ability to cancel requests, proved to have more than one way of being turned against servers. CERT’s vendor list for MadeYouReset included affected products such as Apache Tomcat, Netty, gRPC and Varnish. Many other implementations reported they were not affected.

For agencies, the pattern mattered more than any single flaw. Each disclosure sent teams back to the same question of which systems speak HTTP/2 to the public, and through whose software. Agencies that had answered it in October 2023 could reuse the answer. Those that had patched without recording what they patched started again.

Politically motivated campaigns against government sites continued around elections and geopolitical events, mostly causing short disruptions. Public reporting does not allow a systematic comparison of edge-fronted and self-hosted agency services, so we do not claim one.

The guidance agencies needed already existed when Rapid Reset arrived. CISA’s alert pointed to its publications on understanding and responding to denial-of-service attacks, and to additional guidance written for federal agencies. Their core advice was to know which services matter, arrange mitigation before an attack, and plan for degraded operation. That advice aged well, and it is close to the three-group approach in different words.

What did not change is the dependence on inventory. Each new protocol-level flaw again required agencies to find every endpoint that spoke the affected protocol, and the agencies that could do so quickly were the ones that knew who owned each service.

Specific flaws come and go, and each one will be patched. The question that keeps returning is whether the organization knows what it has exposed to the internet, who is responsible for each piece, and what it has decided to accept. An agency that can answer those three things turns the next Rapid Reset from a scramble into a checklist. One that cannot will keep learning about its own services from outages and outsiders, however good its engineers are.