At 17:21 UTC on February 28, 2018, GitHub started taking the largest denial-of-service attack anyone had ever recorded: 1.35 terabits per second, 126.9 million packets per second, slamming in from tens of thousands of endpoints across more than a thousand networks. GitHub’s own edge couldn’t hold it. By 17:26 they had rerouted every bit of inbound traffic to Akamai’s scrubbing centers, and by 17:30 the attack was tapering off. The site was degraded for about ten minutes. A second, smaller spike — around 400 Gbps — showed up after 18:00 and did nothing.
That’s the whole incident. It’s not the interesting part.
The interesting part is that nobody built the weapon. There was no botnet. No malware campaign, no years of quietly infecting home routers and cameras, no command-and-control infrastructure. The largest attack in history at that point was assembled, in minutes, out of servers other people had left lying open — and it was free.
How you turn 15 bytes into 750 kilobytes
The trick was memcached, a caching server that a lot of web applications keep between themselves and their database. Fast, simple, and — this is the part that matters — for years it shipped listening on UDP port 11211 by default, with no authentication of any kind. Anyone who could reach it could talk to it.
UDP is the ingredient that makes this dangerous. It’s connectionless: you send a packet claiming to be from whatever source address you like, and the server replies to that address without ever checking whether you actually live there. So an attacker sends a memcached server a tiny request — ask it to dump a large cached value — but forges the source IP to be the victim’s. The server dutifully fires the response at GitHub.
The asymmetry is what makes it a weapon. Cloudflare, which published its analysis of these attacks the day before GitHub was hit, put the number on it: in practice a 15-byte request could trigger a response of up to 750 kilobytes. That’s an amplification factor around 51,000 — the same order of magnitude CVE-2018-1000115 records (“1:50,000”). You send one byte, the victim receives fifty thousand. A single attacker with a modest, ordinary internet connection can point a firehose of terabits at a target, because they aren’t generating the traffic — thousands of strangers’ servers are, and each one multiplies the attacker’s effort by five orders of magnitude.
Nobody had to be compromised. The memcached servers weren’t hacked. They did exactly what they were built to do, for a request that looked exactly like a legitimate one, from an address that looked exactly like GitHub asking for its own data.
Two failures, both decades old
An amplification attack needs two things to be true at once, and the depressing thing is that both had been solved problems for years.
The first is the reflector: a service that answers unsolicited UDP with a much bigger reply. Memcached on the open internet was a spectacular one, but the genre is old — DNS, NTP, SSDP, and a dozen others have all been abused the same way. The specific failure here was a default. Memcached listened on UDP, publicly, out of the box, and tens of thousands of installations inherited that default without anyone deciding they wanted it. The maintainers’ fix, when it came, was almost insultingly small: version 1.5.6 disabled the UDP port by default. One flag. The feature that powered the largest attack in history was turned off with a one-line change, and almost nobody missed it.
The second failure is the one that actually matters, and it’s the one nobody fixes: the forged source address. None of this works if the attacker can’t lie about where their packets come from. And they can only lie because most networks don’t check. The fix for that has a name and a date — BCP38, Network Ingress Filtering, published as RFC 2827 in the year 2000. It says something obvious: a network should drop outbound packets whose source address doesn’t belong to it. If your customer’s traffic claims to come from GitHub’s IP space, and your customer is not GitHub, don’t forward it.
That is the entire defense against spoofing, and it has been the recommended practice for a quarter of a century. It is still not universally deployed, because of an incentive problem that no RFC can fix: the network that fails to filter is not the network that gets hurt. Filtering costs you effort and equipment to protect someone else from your customers’ spoofed traffic. The victim is always somewhere across the internet. So the packets keep flowing, the reflectors keep reflecting, and the attack that should have been impossible in 2001 was setting records in 2018.
The kill switch nobody should have needed
Here’s the detail that turns the whole thing from scary to farcical. Because an open memcached server accepts commands from anyone, a defender under attack could send the reflectors the very commands that disarm them. Corero Network Security demonstrated it within days: fire a flush_all at the abused servers to wipe the cached payload the attacker planted, and the reflected responses shrink to nothing. A shutdown command, where the server accepts it, turns the reflector off entirely. Researchers wrapped it in a tool, pointed it at the list of exposed servers, and the whole record-breaking attack class had an off switch.
Think about what that means. The same missing authentication that let attackers weaponize these servers let defenders reach in and switch them off. The servers were so open that both sides could operate them. The vulnerability and its emergency mitigation were the same flaw, viewed from two directions.
The record didn’t survive the week
If you want the clearest possible sign that this was a structural problem and not a one-off, look at the calendar. GitHub took 1.35 Tbps on February 28. Within a week — in a post dated March 5 — NETSCOUT’s Arbor group confirmed a 1.7 Tbps memcached attack against a US service provider’s customer. The previous record their global sensors had ever seen was 650 Gbps, back in 2016. In about a week, memcached amplification had broken the all-time record twice and pushed it to more than two and a half times where it had stood.
That’s what happens when the raw material for a record-breaking attack is just sitting there, free, waiting for anyone who reads the CVE. The size of these attacks was never limited by the attackers’ resources. It was limited only by how many open reflectors existed, and there were plenty.
The lesson isn’t about memcached
It’s tempting to file this under “misconfigured caching server, now patched” and move on. That misses it. Memcached’s default was changed within days of the first big attacks. The reflector du jour changes — it was NTP before, it’ll be something else next — but reflectors are cheap to find and cheap to fix once someone points at them.
The load-bearing failure was BCP38, and BCP38 is still not deployed, because the economics haven’t changed since 2000. Source-address validation is a favor you do for strangers at your own expense. The people who could stop spoofing at the source are not the people who eat the terabits, so they don’t, and every few years a new reflector reminds us that the internet still lets you forge your return address. We keep treating each amplification record as a story about the reflector. It’s really a story about a return-address check that everyone agrees is a good idea and almost nobody bothers to run.
The 1.35 Tbps attack lasted eight minutes. The flaw that made it possible has been documented, with its fix, for twenty-six years.