The GitHub 1.35 Tbps DDoS Attack (2018)

On February 28, 2018, GitHub was hit by the largest distributed denial-of-service (DDoS) attack ever recorded at that time: a sustained flood peaking at 1.35 terabits per second (Tbps) of inbound traffic. The attack used a relatively new amplification technique that exploited misconfigured memcached servers across the internet, and it required no botnet at all. Despite the unprecedented volume, Akamai Prolexic absorbed and mitigated the attack in roughly ten minutes. The incident fundamentally changed how the internet community thinks about UDP-based amplification and exposed services.

What is Memcached?

Memcached is an open-source, high-performance, distributed memory caching system. It is designed to speed up dynamic web applications by caching data and objects in RAM to reduce the number of times an application must read from a database. Companies like Facebook, Wikipedia, and Twitter use memcached at massive scale internally.

Memcached was designed to run on trusted internal networks. It has no authentication mechanism, no access control, and no encryption. If you can reach a memcached server, you can read from and write to its cache. This is fine behind a firewall, but by 2018, hundreds of thousands of memcached servers were exposed directly to the public internet on UDP port 11211 -- reachable by anyone.

The Amplification Technique

The attack exploited a class of vulnerability known as a reflection and amplification attack. The concept is straightforward: the attacker sends a small request to a third-party server, spoofing the source IP address to be the victim's address. The server then sends a much larger response to the victim. The attacker never communicates with the victim directly.

What made memcached uniquely dangerous was the amplification factor. A memcached GET request can be as small as 15 bytes, but if the cache key stores a large value, the response can be hundreds of kilobytes or even a megabyte. Researchers measured amplification factors as high as 51,000x -- meaning a single byte of attacker traffic could generate 51,000 bytes of traffic directed at the victim. For comparison, DNS amplification attacks typically achieve a factor of 28-54x, and NTP amplification tops out around 556x. Memcached blew every previous amplification vector out of the water.

Why UDP Made This Possible

The attack depended entirely on UDP (User Datagram Protocol). Unlike TCP, UDP is connectionless -- there is no handshake, no session, no verification that the source IP address is legitimate. When a memcached server receives a UDP request claiming to be from a certain IP address, it sends the response to that IP without question. This is what makes source IP spoofing trivial with UDP.

Memcached supports both TCP and UDP, but the UDP listener was enabled by default in all versions prior to 1.5.6. Most operators who deployed memcached on internet-facing servers either did not realize UDP was enabled or did not understand the implications. The memcached protocol over UDP was originally intended for performance optimization in trusted data center environments where the overhead of TCP connection setup was undesirable.

Anatomy of the GitHub Attack

Before the attack, the adversary likely spent days or weeks preparing. The preparation phase involved two steps:

1. Scanning -- The attacker scanned the internet for memcached servers with UDP port 11211 open. Shodan and Censys data from early 2018 showed roughly 100,000 exposed memcached instances worldwide, though some estimates ranged higher.
2. Priming -- The attacker sent SET commands to these memcached servers, storing large payloads (hundreds of kilobytes) under known cache keys. This ensured that when the GET requests came during the attack, the responses would be as large as possible.

Then, on February 28, the attacker launched the assault. The sequence unfolded rapidly:

The first wave struck at 17:21 UTC and peaked almost instantly at 1.35 Tbps -- approximately 126.9 million packets per second. To put that in perspective, this was more than double the previous record-holding DDoS attack (the 2016 Dyn attack, estimated at around 620 Gbps, which itself was powered by the Mirai botnet's hundreds of thousands of compromised IoT devices). The GitHub attack achieved more than double that bandwidth with zero compromised devices.

GitHub's infrastructure was immediately overwhelmed. The site became intermittently available. GitHub's own network monitoring detected the anomaly within seconds, and their systems automatically initiated a failover to Akamai Prolexic, their contracted DDoS mitigation provider.

How Akamai Prolexic Stopped It

Akamai Prolexic is a DDoS mitigation service that works by rerouting a customer's traffic through Akamai's globally distributed scrubbing centers. The mechanism relies heavily on BGP. Here is how the mitigation worked:

1. BGP reroute -- When GitHub activated Prolexic, Akamai began announcing GitHub's IP prefixes (such as 192.30.252.0/22) from Akamai's own autonomous system. Because anycast distributes Akamai's presence across hundreds of global points, traffic destined for GitHub was now attracted to the nearest Akamai scrubbing center instead of GitHub's origin servers.
2. Traffic scrubbing -- At each scrubbing center, Akamai's systems inspected the incoming traffic. The memcached amplification flood consisted of UDP packets on port 11211 carrying memcached responses that nobody at GitHub had requested. These were trivially distinguishable from legitimate web traffic (which arrives via TCP on ports 80 and 443). The attack traffic was dropped; legitimate traffic was forwarded to GitHub through a clean tunnel.
3. Capacity absorption -- The key factor is scale. No single data center can absorb 1.35 Tbps. But because Akamai operates scrubbing infrastructure in dozens of locations worldwide, the attack traffic was distributed across all of them. Each location only needed to handle a fraction of the total volume. This is the same principle behind CDN architecture and anycast DDoS defense.

Within about eight minutes of rerouting, the attack was fully contained. A second wave struck around 17:30 UTC, peaking at approximately 400 Gbps, but Akamai absorbed it without any impact on GitHub's availability. The entire incident, from the first spike to full mitigation, lasted roughly ten minutes.

The BGP Mechanics of DDoS Mitigation

The GitHub incident is a textbook example of how BGP is used defensively. Under normal operation, GitHub announces its own IP prefixes to the internet from its own autonomous system. Traffic flows directly to GitHub's servers.

When a DDoS attack overwhelms GitHub's capacity, the mitigation provider takes over by advertising the same prefixes from its own network. Because BGP path selection considers AS path length, local preference, and other attributes, the mitigation provider's routes can be made more attractive than GitHub's direct routes. Traffic globally converges on the mitigation provider's scrubbing infrastructure, where malicious packets are discarded and clean traffic is tunneled back to GitHub.

This approach is sometimes called BGP-based traffic diversion or remote triggered black hole (RTBH) routing in its more aggressive form. The critical requirement is that the mitigation provider must have enough aggregate bandwidth, distributed across enough locations, to absorb the full volume of the attack. In 2018, Akamai's Prolexic network had over 2.3 Tbps of dedicated scrubbing capacity globally -- enough to handle the 1.35 Tbps peak.

Comparing Amplification Vectors

The memcached amplification factor is extraordinary when placed alongside other commonly abused protocols:

DNS amplification, which had been the workhorse of DDoS attacks for years, achieves a maximum of about 54x amplification by sending a small query for a large DNS response (typically using EDNS0 and the ANY query type). NTP amplification, which powered the 400 Gbps Spamhaus attack of 2014, achieves about 556x by exploiting the monlist command. Memcached's 51,000x factor is nearly 100 times more efficient than NTP amplification.

The practical implication is staggering. An attacker with a 1 Gbps internet connection and a list of exploitable memcached servers could, in theory, generate over 51 Tbps of attack traffic -- far more than any organization or even most mitigation providers could absorb. The only saving grace is that the number of open memcached servers is finite and was shrinking rapidly as operators patched their systems after the GitHub attack became public.

No Botnet Required

Previous record-setting DDoS attacks required botnets -- large networks of compromised devices. The 2016 Mirai botnet that took down Dyn (and temporarily disrupted Twitter, Netflix, Reddit, and GitHub itself) consisted of an estimated 100,000 compromised IoT devices like cameras and DVRs. Building and maintaining a botnet requires significant effort: finding vulnerable devices, exploiting them, deploying command-and-control infrastructure, and evading takedowns.

The memcached attack required none of this. The attacker needed only:

• A list of IP addresses for open memcached servers (easily found via internet scanning tools like Shodan)
• The ability to send spoofed UDP packets (available from many hosting providers and networks that do not implement BCP38 source address validation)
• Knowledge of the memcached protocol (publicly documented and trivial to implement)

This dramatically lowered the barrier to entry for launching record-breaking DDoS attacks. A single attacker with modest resources could generate traffic volumes that previously required coordinated botnets of tens of thousands of devices.

BCP38 and Source Address Validation

All UDP reflection attacks depend on IP source address spoofing -- the attacker sends packets with a forged source address (the victim's IP) so the reflector sends its response to the victim. If every network on the internet implemented BCP38 (RFC 2827), which mandates that networks should filter outbound traffic and only allow packets with source addresses from their own assigned ranges, spoofed-source attacks would be impossible.

In practice, BCP38 adoption remains incomplete. While most large ISPs and cloud providers implement ingress filtering, many smaller networks, hosting providers, and enterprise networks do not. Attackers specifically seek out networks that allow spoofed traffic to originate their attacks. The Spoofer Project, run by CAIDA, continuously measures BCP38 adoption and has found that roughly a quarter of tested networks still allow some degree of spoofing.

The Aftermath: Securing Memcached

The GitHub attack triggered an immediate, global response. Within days:

• Memcached 1.5.6 was released on March 2, 2018 -- just two days after the attack. This version disabled UDP by default. Operators who needed UDP had to explicitly opt in by passing -U 11211 at startup. Previously, UDP was enabled by default alongside TCP.
• Cloud providers acted -- Major cloud platforms including AWS, Google Cloud, and Azure began blocking or rate-limiting outbound UDP port 11211 traffic. Some sent notifications to customers running exposed memcached instances.
• ISPs deployed filters -- Many transit providers and ISPs implemented filters to drop memcached traffic (UDP port 11211) at their network edge, treating it similarly to how they had previously filtered NTP monlist traffic.
• Mass patching -- The number of exposed memcached servers on the internet dropped precipitously. Shadowserver Foundation tracking showed a decline from roughly 100,000 exposed instances to under 20,000 within weeks, and the number continued falling.

Security researchers at Cloudflare, Akamai, Arbor Networks (now NETSCOUT), and others published detailed analyses, amplification measurement data, and mitigation guidance within hours of the attack. The speed of the community response reflected the severity of the threat: memcached amplification had the potential to generate attacks far larger than anything the internet's infrastructure could absorb if widely exploited.

Why GitHub?

GitHub never disclosed the attacker's identity or motivation, and no group publicly claimed responsibility. GitHub is a high-profile target that would generate maximum media attention, which may have been the point -- many DDoS attacks are motivated by the desire to demonstrate capability rather than by a specific grievance.

It is also worth noting that the attack was not particularly sophisticated in its targeting. The flood was a volumetric assault aimed at overwhelming GitHub's inbound bandwidth. It did not attempt to exploit application-layer vulnerabilities, target specific repositories, or exfiltrate data. This is consistent with a demonstration or proof-of-concept attack using the then-new memcached amplification vector.

Historical Context: The DDoS Arms Race

The GitHub attack was the apex of a long escalation in DDoS attack volumes, driven by the discovery of increasingly powerful amplification vectors:

• 2013 -- The Spamhaus attack peaked at 300 Gbps using DNS amplification, setting a record at the time.
• 2014 -- NTP amplification attacks reached 400 Gbps by exploiting the monlist command in older NTP servers.
• 2016 -- The Mirai botnet generated approximately 620 Gbps against the DNS provider Dyn, disrupting major websites including Twitter, Reddit, and Netflix. This attack used raw volumetric flooding from compromised IoT devices rather than amplification.
• 2018 -- The GitHub memcached attack reached 1.35 Tbps, shattering all previous records with a fraction of the infrastructure required by Mirai.

After 2018, the DDoS landscape continued to evolve. The memcached vector was largely neutralized through patching, but new amplification protocols continued to emerge (CLDAP, WS-Discovery, ARMS). By 2023-2024, DDoS attacks exceeding 1 Tbps had become relatively routine for large mitigation providers, driven by a combination of improved botnets, new amplification vectors, and volumetric attacks targeting cloud infrastructure.

Lessons for Network Operators

The GitHub memcached attack highlighted several enduring lessons for anyone operating internet infrastructure:

• Never expose internal services to the public internet. Memcached has no authentication. Neither do many other internal services (Redis, Elasticsearch clusters, database admin panels). Running them on publicly routable IPs without firewall rules is an invitation for abuse.
• Disable UDP where it is not needed. If a service supports both TCP and UDP and you only need TCP, disable the UDP listener. UDP's connectionless nature makes it inherently more susceptible to spoofing and amplification.
• Implement BCP38. If you operate a network, ensure that outbound packets can only carry source addresses that belong to your network. This is the single most effective measure the internet community can take to prevent reflection attacks.
• Have a DDoS mitigation plan. GitHub's fast recovery was possible because they had a pre-existing relationship with Akamai Prolexic and automated failover procedures. The BGP reroute was triggered within minutes. Organizations without mitigation contracts or on-demand scrubbing services face extended outages.
• Monitor for anomalous traffic. GitHub's systems detected the attack within seconds. Early detection is critical for activating mitigation before services are fully overwhelmed.

The Role of BGP in DDoS Defense

BGP is both the enabler of DDoS defense and, in some ways, a contributing factor to DDoS vulnerability. The ability to reroute traffic by changing BGP announcements is what makes services like Akamai Prolexic and Cloudflare Magic Transit possible. When an attack hits, the mitigation provider advertises the victim's prefixes, attracting attack traffic to distributed scrubbing centers where it can be filtered.

At the same time, BGP's global propagation delay -- the time it takes for route changes to converge across all networks -- means there is always a gap between when mitigation is activated and when it becomes fully effective. During the GitHub attack, this convergence window was the ~5 minutes during which GitHub was partially unreachable. Modern mitigation providers use techniques like always-on routing (where traffic permanently flows through scrubbing infrastructure, even when there is no attack) to eliminate this convergence gap entirely.

The defense against volumetric DDoS attacks is fundamentally a routing problem. The attacker generates more traffic than the victim's links can carry. The solution is to distribute that traffic across enough links and locations that no single point is overwhelmed. Anycast and BGP make this distribution possible. The GitHub attack proved that this model works, even at previously unimaginable traffic volumes.

Explore the Networks Involved

You can examine the routing infrastructure of the key players in this incident using the looking glass:

• AS36459 -- GitHub's autonomous system
• AS20940 -- Akamai, GitHub's DDoS mitigation provider
• AS13335 -- Cloudflare, another major DDoS mitigation and CDN provider
• github.com -- Resolve GitHub's current IP and see its BGP route
• 192.30.252.0 -- One of GitHub's well-known IP prefixes