The unprotected memcached finding (Nessus plugin 52633) means a memcached cache on port 11211 answers anyone who can reach it, with no authentication. Fix it by binding memcached to 127.0.0.1 or a private interface with -l, disabling UDP with -U 0, firewalling port 11211 to your application servers, and enabling SASL if remote clients must connect.
What the scanner is actually detecting
memcached is an in-memory key-value cache. Out of the box it has no login step: any client that opens a TCP connection to port 11211 can send commands such as stats, get, set and flush_all. The upstream man page says the -l listen option is important “as there is no other way to secure the installation”, and when -l is not set memcached listens on every interface (INADDR_ANY).
Two Tenable plugins are usually involved:
| Scanner | Finding | What triggers it |
|---|---|---|
| Nessus 52633 | Unprotected memcached | Tenable’s synopsis: memcached is running on a public IP address. Rated Medium. Tenable’s solution is to firewall the host and restrict the port to authorized hosts. |
| Nessus 26197 | memcached Detection | A service detection plugin that reports memcached listening on the port. Rated Info. Its solution recommends enabling SASL when memcached runs on untrusted networks. |
26197 on its own only tells you memcached exists. 52633 is the one that needs action, and the fix below closes both from any network that should not reach the cache.
Real-world risk
There are two separate problems, and it helps to keep them apart.
- Anyone who reaches TCP 11211 controls the cache. They can read values for keys they know or guess, and on recent versions dump key names with lru_crawler metadump all. They can overwrite cached values, which matters if your application caches sessions, rendered pages or permission lookups, and they can wipe the cache with flush_all, pushing the full load back onto your database. How serious this is depends entirely on what your application stores there.
- UDP reflection and amplification. If UDP is enabled, an attacker can store a large item, then send small spoofed requests so your server fires large responses at a victim. The NVD entry for CVE-2018-1000115 notes that amplification of 1:50,000 has been reported. memcached 1.5.6 disabled UDP by default for this reason, so older builds, or configs that re-enable it, are the ones at risk.
This finding does not give an attacker a shell on the host. A memcached reachable from the internet should be fixed immediately; one reachable only from a single application VLAN is lower priority hardening. If you do not know which hosts expose 11211 externally, that is exactly what an external attack surface management review should tell you.
How to confirm it on the host
Check the version, the listening sockets and the startup options:
# Version (UDP is off by default from 1.5.6)
memcached -V
# Listening sockets: 0.0.0.0, * or [::] means all interfaces; a udp line means UDP is on
ss -tulpn | grep 11211
# Options the running daemon was started with
ps -o args= -C memcached
# Config files
cat /etc/memcached.conf # Debian, Ubuntu
cat /etc/sysconfig/memcached # RHEL, CentOS Stream, Fedora
# Runtime settings (only works while SASL is off)
printf 'stats settingsrnquitrn' | nc 127.0.0.1 11211 | grep -E 'tcpport|udpport|inter|auth_enabled_sasl'STAT inter NULL means no -l was given, so memcached is on every interface. A non-zero udpport means UDP is enabled.
If memcached runs in a container, check the published ports instead, since the container’s internal bind address is not what the network sees:
docker ps --format '{{.Names}} {{.Ports}}' | grep 11211Then test from a different machine, ideally from the scanner’s network segment:
# TCP: an exposed server prints STAT lines ending with END
printf 'statsrnquitrn' | nc -w 3 <host> 11211
# TCP and UDP with Nmap (UDP scanning needs root)
nmap -sT -sU -p T:11211,U:11211 --script memcached-info <host>How to fix it
Debian and Ubuntu: /etc/memcached.conf
The memcached documentation notes that Debian and Ubuntu bind to 127.0.0.1 by default, so a finding here usually means someone commented out or changed the -l line. The file takes one option per line:
cp -a /etc/memcached.conf /etc/memcached.conf.bak.$(date +%F)# Only listen on localhost (or a private address, see below)
-l 127.0.0.1
# Disable UDP explicitly, whatever the version default
-U 0systemctl restart memcachedRHEL, CentOS Stream and Fedora: /etc/sysconfig/memcached
The packaged systemd unit passes $OPTIONS from this file to the daemon. Current Fedora and CentOS Stream 9 packages ship OPTIONS=”-l 127.0.0.1,::1″; older or edited files may have an empty OPTIONS line. Set:
cp -a /etc/sysconfig/memcached /etc/sysconfig/memcached.bak.$(date +%F)PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS="-l 127.0.0.1,::1 -U 0"systemctl restart memcachedApplication servers on other hosts
If web or app servers connect over the network, bind to the private interface they use, never to a public address. The man page allows several addresses separated by commas. Keep comments on their own lines, not after the value. In /etc/memcached.conf:
-l 10.0.10.5,127.0.0.1
-U 0In /etc/sysconfig/memcached:
OPTIONS="-l 10.0.10.5,127.0.0.1 -U 0"Optional extra hardening from the upstream help text: -F disables the flush_all command, and -X disables stats cachedump and lru_crawler metadump.
Containers
Do not publish 11211 at all if only other containers need it; attach them to the same Docker network. If the host itself needs it, publish on loopback only:
docker run -d --name memcached -p 127.0.0.1:11211:11211 memcachedDocker’s documentation warns that Docker and ufw are incompatible: published container ports are routed before ufw rules apply, so a ufw deny rule does not protect a port published on 0.0.0.0.
Firewall TCP and UDP 11211
Apply this in addition to binding, not instead of it. Allow only the application subnet:
# firewalld: remove any blanket opening (a warning is normal if none exists), then allow the app subnet
firewall-cmd --permanent --remove-port=11211/tcp
firewall-cmd --permanent --remove-port=11211/udp
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.10.0/24" port port="11211" protocol="tcp" accept'
firewall-cmd --reload
# ufw: the allow rule must come before the deny
ufw allow from 10.0.10.0/24 to any port 11211 proto tcp
ufw deny 11211When remote clients need authentication: SASL
SASL requires a memcached built with –enable-sasl (1.4.3 or later) and clients that support it. Check and create a user:
memcached -h | grep -i sasl
ldd "$(command -v memcached)" | grep -i sasl
saslpasswd2 -a memcached -c cacheuserThen add -S to the options and restart. Per the upstream SASL howto, -S enables the SASL commands, requires the binary protocol only, and requires successful authentication before any other command. Two caveats from the same documentation: SASL provides authentication, not encryption, and it is not suitable for use over the internet. If PLAIN authentication fails on RHEL-family systems, install cyrus-sasl-plain and make sure the password database is readable by the memcached user.
For ASCII-only clients, memcached 1.5.15 added an experimental -Y auth file for the text protocol, which also disables UDP and the binary protocol. For encryption on the wire, memcached 1.5.13 and later supports TLS with -Z when built with –enable-tls.
How to verify the fix and rescan
- On the host, ss -tulpn | grep 11211 should show only 127.0.0.1, ::1 or your private address, and no UDP line.
- Confirm the application still gets cache hits: check its logs, or run stats locally and watch curr_connections and get_hits rise (not possible over ASCII once SASL is on).
- From an outside host, printf ‘statsrnquitrn’ | nc -w 3 <host> 11211 should time out, be refused, or (with SASL) close without returning STAT lines.
- Run the Nmap memcached-info script again and confirm it returns nothing on TCP or UDP.
- Rescan with the same scanner from the same source address. If the scanner sits inside the allowed subnet, 26197 can legitimately remain as an Info result.
What can break and how to roll back
- Remote app servers lose the cache. After binding to localhost, clients on other hosts get connection errors or constant misses, and database load climbs. Bind the private interface and allow their subnet.
- IPv6 localhost. A client configured for localhost may resolve to ::1. If you bind only 127.0.0.1, add ::1 or point the client at 127.0.0.1.
- UDP clients. Rare, but anything using UDP stops working after -U 0. Move it to TCP.
- SASL. Clients that only speak the ASCII protocol, or lack credentials, are disconnected.
- Cold cache. memcached keeps data in memory, so a restart empties it. Restart off-peak if your database depends heavily on the cache.
To roll back, restore the backup and restart:
cp -a /etc/memcached.conf.bak.YYYY-MM-DD /etc/memcached.conf # Debian, Ubuntu
cp -a /etc/sysconfig/memcached.bak.YYYY-MM-DD /etc/sysconfig/memcached # RHEL family
systemctl restart memcachedCommon false positive reasons
- A different device answered. NAT, a port forward or a load balancer can send 11211 to another host. Check which machine actually owns the socket.
- Something else speaks the protocol. A memcached-compatible proxy or cache can trigger detection. The exposure is still real, but the fix lives in that product’s configuration.
- The scanner is trusted. 52633 keys on a public IP address. If the scanner sits inside an allowed range, verify from a genuinely untrusted network before closing or escalating.
- Stale result. The config was changed but the service was not restarted, or the report predates the change.
FAQ
Is memcached UDP disabled by default?
From version 1.5.6, yes. Setting -U 0 explicitly (the line the upstream advisory shows) costs nothing and protects you if a package or old config re-enables it.
Is SASL enough to expose memcached to the internet?
No. The memcached documentation says SASL does not encrypt traffic and should not be used over the internet. Keep memcached on private networks.
Does binding to 127.0.0.1 affect performance?
No. It only changes which interfaces accept connections. The risk is breaking remote clients, not speed.
Why is memcached Detection (26197) still reported?
The scanner can still reach the port, usually because it scans from an allowed subnet. It is informational; what matters is that untrusted networks cannot connect.
Tracking this finding across many hosts
Exposed caches tend to show up on several application servers at once. A platform such as SITEY can import Nessus results (as an uploaded .nessus export), have AI draft a host-specific change to the memcached config that runs through its Linux agent only after human approval, and then re-test each Nessus finding to confirm it closed. Duplicates are merged per scanner rather than across scanners, so expect a separate entry for each tool that reported the host.