logo

Port 11211 – Memcached (Distributed Memory Object Caching System)

Service:

memcached daemon

Protocol:

TCP/UDP

Port:

11211

Used for:

High-performance distributed in-memory caching of database query results, sessions, rendered fragments, and API responses to speed up dynamic web applications

Port 11211 is the default port for Memcached, a high-performance, distributed in-memory object caching system used to keep an application’s hottest data — database query results, rendered page fragments, session objects, API responses — in RAM instead of hitting the backing store on every request. The memcached daemon listens on 11211 over both TCP and UDP, and it speaks a deliberately minimal, unauthenticated text protocol: connect and you can run stats, get, set, and flush_all with no login at all. That simplicity is the whole problem. An exposed port 11211 lets anyone dump every cached key — session tokens, cached DB rows, PII — then rewrite or wipe the cache, and because the historic UDP listener answered tiny spoofed requests with enormous replies, it became one of the most powerful DDoS reflectors ever seen, behind the record-breaking 2018 attacks on GitHub.

Why It’s Open

Memcached is one of the most widely deployed caching layers on the web, sitting in front of the database for WordPress, Django, Rails, Laravel, and countless custom stacks, as well as large platforms like Facebook that popularised it. It exists to offload reads from a slower persistent store, so by design it holds transient but often sensitive data and answers as fast as possible. In a healthy deployment it binds to 127.0.0.1 or a private app-tier address and only ever talks to trusted application servers.

The port becomes a liability when the daemon is bound to 0.0.0.0 — historically the out-of-the-box behaviour on older packages, and still a common outcome of a quick-start guide, a container image with a wide-open listener, or a cloud security group that’s broader than intended. Older Memcached builds also enabled the UDP listener by default, which is what turned exposed instances into mass DDoS reflectors. Where Memcached is exposed to untrusted networks, its data-store siblings frequently are too: check for Redis on port 6379 — its closest cousin, an unauthenticated in-memory store — along with MongoDB on 27017, Elasticsearch on 9200, and Microsoft SQL Server on 1433.

Common Risks

  • No authentication by default. The classic finding. The default text protocol has no password whatsoever, so anyone who can reach 11211 runs telnet <target> 11211, issues stats, and has full read/write control of the cache. SASL authentication exists but must be explicitly enabled and is very rarely turned on.
  • Full cache disclosure. stats items and stats cachedump <slab> <limit> enumerate the keys an instance is holding, and get <key> returns the value. Session identifiers, JWTs, password-reset tokens, API keys, and cached database rows containing PII routinely sit in Memcached in plaintext — a walk of the slabs is often an instant session-hijack or credential harvest.
  • Cache poisoning and destruction. With set an attacker can overwrite cached objects (feeding tampered data straight into the application), and flush_all wipes the entire cache in one command, forcing every request onto the origin database as a denial-of-service amplifier.
  • UDP reflection / amplification DDoS. The marquee risk. A spoofed stats or get request of a few bytes provokes a reply thousands of times larger, letting attackers reflect and amplify traffic at a victim by roughly 10,000×–51,000× — the mechanism behind the 1.35 Tbps GitHub attack (see below).
  • Integer-overflow RCE in the binary protocol. The 2016 Cisco Talos findings (CVE-2016-8704/8705/8706) showed that crafted binary-protocol commands could overflow the heap and lead to remote code execution on unpatched daemons.
  • Cleartext everywhere. Memcached has no transport encryption in its common configuration; keys, values, and any SASL exchange cross the network in the clear and can be sniffed on the path.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

logo-cta

Enumeration & Testing

Detect the service and grab the version banner

Terminal window
nmap -sV -p 11211 <target>

Run the Memcached NSE script

Terminal window
nmap -p 11211 --script memcached-info <target>

memcached-info pulls the version, architecture, process ID, uptime, connection counts, and the list of active slabs from an unauthenticated instance.

Check the UDP listener (amplification exposure)

Terminal window
nmap -sU -sV -p 11211 <target>

A responsive UDP 11211 is the reflector risk — an open UDP listener answering stats is exactly what DDoS operators scan for.

Talk to the text protocol directly

Terminal window
telnet <target> 11211
# then, interactively:
stats # version, OS, PID, curr_items, bytes, connection stats
stats items # per-slab item counts and ages
stats cachedump 1 100 # dump up to 100 keys from slab class 1
get <key> # retrieve a cached value

nc <target> 11211 works the same way if you prefer piping commands in non-interactively.

Enumerate and dump with libmemcached tools

Terminal window
memcstat --servers=<target> # server stats without a manual telnet session
memcdump --servers=<target> # list every key the server is holding
memccat --servers=<target> <key> # print the value for a specific key

Metasploit modules

Terminal window
msfconsole -q
# Dump all key/value pairs from an exposed instance
use auxiliary/gather/memcached_extractor
set RHOSTS <target>
run
# UDP version fingerprint
use auxiliary/scanner/memcached/memcached_udp_version
set RHOSTS <target>
run
# Test whether the host is usable as a UDP amplifier
use auxiliary/scanner/memcached/memcached_amp
set RHOSTS <target>
run

Log every open instance, the dumped keys, and whether UDP answers, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Checkpoint What it means
stats returns with no authentication No access control — full read/write of the cache
stats cachedump / memcdump lists keys The whole dataset is enumerable and dumpable
Cached session tokens, JWTs, or PII in values Instant session hijack or credential harvest
set / flush_all accepted Cache poisoning and cache-wipe DoS are possible
UDP 11211 answers stats Usable as a high-ratio DDoS reflector/amplifier
Bound to 0.0.0.0, reachable off-host Exposed beyond the app tier; often internet-facing
Old version in stats (≤ 1.4.31) Check the 2016 binary-protocol RCE CVEs
No SASL / no TLS negotiated Unauthenticated and sniffable

Known CVEs and Exploits

Memcached’s most damaging real-world issue is a design and exposure problem, not a memory-corruption bug: an instance on the public internet with no authentication and a UDP listener is dangerous the moment it’s reachable, with or without a CVE. The named vulnerabilities that matter are the UDP amplification advisory and a cluster of 2016 binary-protocol overflows:

  • CVE-2018-1000115 — The amplification vulnerability. Memcached’s UDP support on port 11211 has no access control and answers spoofed requests with vastly larger replies (amplification on the order of tens of thousands to one), enabling reflected denial-of-service floods. This is the flaw behind the 2018 “Memcrashed” attacks. It was effectively fixed in Memcached 1.5.6, which disables the UDP protocol by default. CVSS 3.x 7.5 (HIGH), CWE-400.
  • CVE-2016-8704 — An integer overflow in the process_bin_append_prepend function (append/prepend handling in the binary protocol) causes a heap overflow that can lead to remote code execution. Discovered by Cisco Talos; affects Memcached 1.4.31 and earlier. CVSS 3.x 9.8 (CRITICAL), CWE-190.
  • CVE-2016-8705 — Multiple integer overflows in the process_bin_update function (the binary-protocol update path) cause a heap overflow and potential remote code execution. Also from Cisco Talos; affects 1.4.31. CVSS 3.x 9.8 (CRITICAL), CWE-190.
  • CVE-2016-8706 — An integer overflow in process_bin_sasl_auth, the routine that handles SASL authentication commands, causes a heap overflow that can lead to remote code execution. Affects 1.4.31. CVSS 3.x 8.1 (HIGH), CWE-190. (Ironically, it lives in the authentication handler — the feature meant to make Memcached safer.)

All three 2016 overflows are fixed in Memcached 1.4.33 and later. Note that they require the daemon to be reachable and, for the SASL bug, that binary-protocol authentication be in use — which is exactly why unauthenticated internet exposure, not the CVEs alone, remains the dominant risk on this port.

Mitigation

  • Never expose 11211 to the internet. Bind Memcached to 127.0.0.1 or a private app-tier address (-l 127.0.0.1), keep it on an internal subnet, and firewall the port to the specific application servers that need it.
  • Disable the UDP listener. Start memcached with -U 0 to turn off UDP entirely (the default since 1.5.6). This removes the reflection/amplification capability outright and is the single most important hardening step for any reachable instance.
  • Enable SASL authentication. Build/run with SASL (-S) so clients must authenticate, instead of relying on the default no-auth text protocol — and use strong credentials.
  • Don’t cache secrets in the clear. Avoid storing raw session tokens, credentials, or sensitive PII in Memcached where possible; where you must, treat an exposed cache as a full disclosure.
  • Patch. Run a current Memcached (≥ 1.5.6 for the UDP default, ≥ 1.4.33 for the 2016 overflows) so both the amplification default and the binary-protocol RCEs are closed.
  • Segment and monitor. Put the cache on a restricted network segment, and alert on unexpected flush_all, mass get/cachedump activity, or any traffic to 11211 from outside the app tier.

Real-World Example

On 28 February 2018, GitHub was hit by what was then the largest DDoS attack ever recorded — a 1.35 Tbps flood that peaked in minutes and was mitigated by Akamai Prolexic. The attack used no botnet of infected devices at all: instead, the attackers sent small, spoofed UDP requests to thousands of exposed Memcached servers on port 11211, each of which replied to GitHub’s spoofed address with a response tens of thousands of times larger. Dubbed “Memcrashed,” the technique exploited exactly the flaw later tracked as CVE-2018-1000115 — an open UDP listener with no access control and an amplification ratio measured in the tens of thousands. Days later, on 5 March 2018, NETSCOUT Arbor reported an even bigger 1.7 Tbps Memcached-reflection attack against a US service provider. The fallout drove the Memcached project to ship 1.5.6 with UDP disabled by default, and it remains the textbook case for why an unauthenticated, internet-reachable cache port is a network-scale liability, not just a local one. Redis on port 6379, SSDP on 1900, SNMP on 161, and NTP on 123 are the other classic UDP-amplification cousins worth checking on the same engagement.

FAQ

What is port 11211 used for?

Port 11211 is the default port for Memcached, a distributed in-memory object caching system that stores database query results, session data, rendered fragments, and API responses in RAM to speed up dynamic web applications. The memcached daemon listens on 11211 over both TCP and UDP and answers a simple text protocol. In a secure setup it is only reachable from the application servers or localhost, never the public internet.

Is port 11211 dangerous?

It is when it’s exposed. Memcached’s default protocol has no authentication, so anyone who can reach an open 11211 can dump every cached key (often including session tokens and PII), poison or wipe the cache, and — if the UDP listener is on — abuse the server as a massive DDoS reflector. Port 11211 should be firewalled to trusted clients, have UDP disabled, and never be left open to the internet.

What service runs on port 11211?

The Memcached daemon (memcached). Managed caching offerings from cloud providers use the same default port, and Memcached’s closest sibling, Redis, runs the same class of unauthenticated in-memory store on port 6379.

Why was Memcached used in the record 2018 DDoS attacks?

Because older Memcached builds enabled a UDP listener on 11211 with no access control, and a tiny spoofed request produced a reply tens of thousands of times larger. Attackers spoofed a victim’s IP, sprayed requests at thousands of exposed servers, and reflected the amplified responses at the target — reaching 1.35 Tbps against GitHub and 1.7 Tbps against a service provider (CVE-2018-1000115). The fix was to disable UDP by default in version 1.5.6.

How do I secure or close port 11211?

Bind Memcached to 127.0.0.1 or an internal address (-l 127.0.0.1), disable UDP with -U 0, enable SASL authentication (-S) with strong credentials, firewall 11211 to known application servers, avoid caching secrets in the clear, and keep the daemon patched (≥ 1.5.6). If nothing external needs it, confirm the port isn’t reachable off-host with a rescan and record the result in your pentest report.

TL;DR

  • Service: Memcached distributed in-memory object caching system (memcached daemon)
  • Default port: 11211/TCP and 11211/UDP
  • Biggest risk: unauthenticated internet exposure — full cache dump (session tokens, PII), cache poisoning/wipe, and UDP reflection/amplification DDoS (the 1.35 Tbps GitHub “Memcrashed” attack, CVE-2018-1000115); older daemons also carry the 2016 binary-protocol RCEs
  • Mitigation: bind to localhost/internal, disable UDP (-U 0), enable SASL auth, firewall to trusted clients, don’t cache secrets in cleartext, and patch to ≥ 1.5.6