{ "id": "ca99712d-d7bc-40c6-bb57-f513dbae19fd", "created_at": "2026-04-06T00:12:31.171029Z", "updated_at": "2026-04-10T13:13:02.997979Z", "deleted_at": null, "sha1_hash": "532b77a1f100430e36487fb1a8509a9dc3341543", "title": "Memcrashed - Major amplification attacks from UDP port 11211", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2683746, "plain_text": "Memcrashed - Major amplification attacks from UDP port 11211\r\nBy Marek Majkowski\r\nPublished: 2018-02-27 · Archived: 2026-04-05 13:48:19 UTC\r\n2018-02-27\r\n4 min read\r\nOver last couple of days we've seen a big increase in an obscure amplification attack vector - using the\r\nmemcached protocol, coming from UDP port 11211.\r\nhttps://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/\r\nPage 1 of 9\n\nCC BY-SA 2.0 image by David TrawinIn the past, we have talked a lot about amplification attacks happening on\r\nthe internet. Our most recent two blog posts on this subject were:\r\nSSDP amplifications crossing 100Gbps. Funnily enough, since then we were a target of an 196Gbps SSDP\r\nattack.\r\nGeneral statistics about various amplification attacks we see.\r\nThe general idea behind all amplification attacks is the same. An IP-spoofing capable attacker sends forged\r\nrequests to a vulnerable UDP server. The UDP server, not knowing the request is forged, politely prepares the\r\nresponse. The problem happens when thousands of responses are delivered to an unsuspecting target host,\r\noverwhelming its resources - most typically the network itself.\r\nhttps://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/\r\nPage 2 of 9\n\nAmplification attacks are effective, because often the response packets are much larger than the request packets. A\r\ncarefully prepared technique allows an attacker with limited IP spoofing capacity (such as 1Gbps) to launch very\r\nlarge attacks (reaching 100s Gbps) \"amplifying\" the attacker's bandwidth.\r\nMemcrashed\r\nObscure amplification attacks happen all the time. We often see \"chargen\" or \"call of duty\" packets hitting our\r\nservers.\r\nA discovery of a new amplification vector though, allowing very great amplification, happens rarely. This new\r\nmemcached UDP DDoS is definitely in this category.\r\nThe DDosMon from Qihoo 360 monitors amplification attack vectors and this chart shows recent\r\nmemcached/11211 attacks:\r\nhttps://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/\r\nPage 3 of 9\n\nThe number of memcached attacks was relatively flat, until it started spiking just a couple days ago. Our charts\r\nalso confirm this, here are attacks in packets per second over the last four days:\r\nWhile the packets per second count is not that impressive, the bandwidth generated is:\r\nAt peak we've seen 260Gbps of inbound UDP memcached traffic. This is massive for a new amplification vector.\r\nBut the numbers don't lie. It's possible because all the reflected packets are very large. This is how it looks in\r\ntcpdump:\r\n$ tcpdump -n -t -r memcrashed.pcap udp and port 11211 -c 10\r\nIP 87.98.205.10.11211 \u003e 104.28.1.1.1635: UDP, length 13\r\nIP 87.98.244.20.11211 \u003e 104.28.1.1.41281: UDP, length 1400\r\nIP 87.98.244.20.11211 \u003e 104.28.1.1.41281: UDP, length 1400\r\nIP 188.138.125.254.11211 \u003e 104.28.1.1.41281: UDP, length 1400\r\nIP 188.138.125.254.11211 \u003e 104.28.1.1.41281: UDP, length 1400\r\nIP 188.138.125.254.11211 \u003e 104.28.1.1.41281: UDP, length 1400\r\nhttps://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/\r\nPage 4 of 9\n\nIP 188.138.125.254.11211 \u003e 104.28.1.1.41281: UDP, length 1400\r\nIP 188.138.125.254.11211 \u003e 104.28.1.1.41281: UDP, length 1400\r\nIP 5.196.85.159.11211 \u003e 104.28.1.1.1635: UDP, length 1400\r\nIP 46.31.44.199.11211 \u003e 104.28.1.1.6358: UDP, length 13\r\nThe majority of packets are 1400 bytes in size. Doing the math 23Mpps x 1400 bytes gives 257Gbps of\r\nbandwidth, exactly what the chart shows.\r\nMemcached does UDP?\r\nI was surprised to learn that memcached does UDP, but there you go! The protocol specification shows that it's\r\none of the best protocols to use for amplification ever! There are absolutely zero checks, and the data WILL be\r\ndelivered to the client, with blazing speed! Furthermore, the request can be tiny and the response huge (up to\r\n1MB).\r\nLaunching such an attack is easy. First the attacker implants a large payload on an exposed memcached server.\r\nThen, the attacker spoofs the \"get\" request message with target Source IP.\r\nSynthetic run with Tcpdump shows the traffic:\r\n$ sudo tcpdump -ni eth0 port 11211 -t\r\nIP 172.16.170.135.39396 \u003e 192.168.2.1.11211: UDP, length 15\r\nIP 192.168.2.1.11211 \u003e 172.16.170.135.39396: UDP, length 1400\r\nIP 192.168.2.1.11211 \u003e 172.16.170.135.39396: UDP, length 1400\r\n...(repeated hundreds times)...\r\n15 bytes of request triggered 134KB of response. This is amplification factor of 10,000x! In practice we've seen a\r\n15 byte request result in a 750kB response (that's a 51,200x amplification).\r\nSource IPs\r\nThe vulnerable memcached servers are all around the globe, with higher concentration in North America and\r\nEurope. Here is a map of the source IPs we've seen in each of our 120+ points of presence:\r\nhttps://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/\r\nPage 5 of 9\n\nInterestingly our datacenters in EWR, HAM and HKG see disproportionally large numbers of attacking IPs. This\r\nis because most of the vulnerable servers are located in major hosting providers. The AS numbers of the IPs that\r\nwe've seen:\r\n┌─ips─┬─srcASN──┬─ASName───────────────────────────────────────\r\n│ 578 │ AS16276 │ OVH │\r\n│ 468 │ AS14061 │ DIGITALOCEAN-ASN - DigitalOcean, LLC │\r\n│ 231 │ AS7684 │ SAKURA-A SAKURA Internet Inc. │\r\n│ 199 │ AS9370 │ SAKURA-B SAKURA Internet Inc. │\r\n│ 165 │ AS12876 │ AS12876 │\r\n│ 119 │ AS9371 │ SAKURA-C SAKURA Internet Inc. │\r\n│ 104 │ AS16509 │ AMAZON-02 - Amazon.com, Inc. │\r\n│ 102 │ AS24940 │ HETZNER-AS │\r\n│ 81 │ AS26496 │ AS-26496-GO-DADDY-COM-LLC - GoDaddy.com, LLC │\r\n│ 74 │ AS36351 │ SOFTLAYER - SoftLayer Technologies Inc. │\r\n│ 65 │ AS20473 │ AS-CHOOPA - Choopa, LLC │\r\n│ 49 │ AS49981 │ WORLDSTREAM │\r\n│ 48 │ AS51167 │ CONTABO │\r\n│ 48 │ AS33070 │ RMH-14 - Rackspace Hosting │\r\n│ 45 │ AS19994 │ RACKSPACE - Rackspace Hosting │\r\n│ 44 │ AS60781 │ LEASEWEB-NL-AMS-01 Netherlands │\r\n│ 42 │ AS45899 │ VNPT-AS-VN VNPT Corp │\r\n│ 41 │ AS2510 │ INFOWEB FUJITSU LIMITED │\r\n│ 40 │ AS7506 │ INTERQ GMO Internet,Inc │\r\n│ 35 │ AS62567 │ DIGITALOCEAN-ASN-NY2 - DigitalOcean, LLC │\r\n│ 31 │ AS8100 │ ASN-QUADRANET-GLOBAL - QuadraNet, Inc │\r\n│ 30 │ AS14618 │ AMAZON-AES - Amazon.com, Inc. │\r\n│ 30 │ AS31034 │ ARUBA-ASN │\r\n└─────┴─────────┴───────────────────────────────────────\r\nhttps://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/\r\nPage 6 of 9\n\nMost of the memcached servers we've seen were coming from AS16276 - OVH, AS14061 - Digital Ocean and\r\nAS7684 - Sakura.\r\nIn total we've seen only 5,729 unique source IPs of memcached servers. We're expecting to see much larger\r\nattacks in future, as Shodan reports 88,000 open memcached servers:\r\nLet's fix it up\r\nIt's necessary to fix this and prevent further attacks. Here is a list of things that should be done.\r\nMemcached Users\r\nIf you are using memcached, please disable UDP support if you are not using it. On memcached startup you can\r\nspecify --listen 127.0.0.1 to listen only to localhost and -U 0 to disable UDP completely. By default\r\nmemcached listens on INADDR_ANY and runs with UDP support ENABLED. Documentation:\r\nhttps://github.com/memcached/memcached/wiki/ConfiguringServer#udp\r\nYou can easily test if your server is vulnerable by running:\r\n$ echo -en \"\\x00\\x00\\x00\\x00\\x00\\x01\\x00\\x00stats\\r\\n\" | nc -q1 -u 127.0.0.1 11211\r\nSTAT pid 21357\r\nSTAT uptime 41557034\r\nSTAT time 1519734962\r\n...\r\nIf you see non-empty response (like the one above), your server is vulnerable.\r\nSystem administrators\r\nhttps://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/\r\nPage 7 of 9\n\nPlease ensure that your memcached servers are firewalled from the internet! To test whether they can be accessed\r\nusing UDP I recommend the nc example above, to verify if TCP is closed run nmap :\r\n$ nmap TARGET -p 11211 -sU -sS --script memcached-info\r\nStarting Nmap 7.30 ( https://nmap.org ) at 2018-02-27 12:44 UTC\r\nNmap scan report for xxxx\r\nHost is up (0.011s latency).\r\nPORT STATE SERVICE\r\n11211/tcp open memcache\r\n| memcached-info:\r\n| Process ID 21357\r\n| Uptime 41557524 seconds\r\n| Server time 2018-02-27T12:44:12\r\n| Architecture 64 bit\r\n| Used CPU (user) 36235.480390\r\n| Used CPU (system) 285883.194512\r\n| Current connections 11\r\n| Total connections 107986559\r\n| Maximum connections 1024\r\n| TCP Port 11211\r\n| UDP Port 11211\r\n|_ Authentication no\r\n11211/udp open|filtered memcache\r\nInternet Service Providers\r\nIn order to defeat such attacks in future, we need to fix vulnerable protocols and also IP spoofing. As long as IP\r\nspoofing is permissible on the internet, we'll be in trouble.\r\nhttps://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/\r\nPage 8 of 9\n\nHelp us out by tracking who is behind these attacks. We must know not who has problematic memcached servers,\r\nbut who sent them queries in the first place. We can't do this without your help!\r\nDevelopers\r\nPlease please please: Stop using UDP. If you must, please don't enable it by default. If you do not know what an\r\namplification attack is I hereby forbid you from ever typing SOCK_DGRAM into your editor.\r\nWe've been down this road so many times. DNS, NTP, Chargen, SSDP and now memcached. If you use UDP, you\r\nmust always respond with strictly a smaller packet size then the request. Otherwise your protocol will be abused.\r\nAlso remember that people do forget to set up a firewall. Be a nice citizen. Don't invent a UDP-based protocol that\r\nlacks authentication of any kind.\r\nThat's all\r\nIt's anyone's guess how large the memcached attacks will become before we clean the vulnerable servers up. There\r\nwere already rumors of 0.5Tbps amplifications in the last few days, and this is just a start.\r\nFinally, you are OK if you are a Cloudflare customer. Cloudflare's Anycast architecture works well to distribute\r\nthe load in case of large amplification attacks, and unless your origin IP is exposed, you are safe behind\r\nCloudflare.\r\nPrologue\r\nA comment (below) points out that the possibility of using memcached for DDoS was discussed in a 2017\r\npresentation.\r\nUpdateWe received a word from Digital Ocean, OVH, Linode and Amazon that they tackled the memcached\r\nproblem, their networks should not be a vector in future attacks. Hurray!\r\nDealing with DDoS attacks sound interesting? Join our world famous team in London, Austin, San Francisco and\r\nour elite office in Warsaw, Poland.\r\nCloudflare's connectivity cloud protects entire corporate networks, helps customers build Internet-scale\r\napplications efficiently, accelerates any website or Internet application, wards off DDoS attacks, keeps hackers at\r\nbay, and can help you on your journey to Zero Trust.\r\nVisit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.\r\nTo learn more about our mission to help build a better Internet, start here. If you're looking for a new career\r\ndirection, check out our open positions.\r\nDDoSDevelopersMitigationReliabilityAttacksVulnerabilities\r\nSource: https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/\r\nhttps://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/\r\nPage 9 of 9", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/" ], "report_names": [ "memcrashed-major-amplification-attacks-from-port-11211" ], "threat_actors": [], "ts_created_at": 1775434351, "ts_updated_at": 1775826782, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/532b77a1f100430e36487fb1a8509a9dc3341543.pdf", "text": "https://archive.orkl.eu/532b77a1f100430e36487fb1a8509a9dc3341543.txt", "img": "https://archive.orkl.eu/532b77a1f100430e36487fb1a8509a9dc3341543.jpg" } }