Memcached Security: Binding, UDP, SASL and TLS Hardening Steps

Memcached is built for speed inside a trusted network, and the project's own documentation is direct that it must not be exposed to the internet or to untrusted users, so its security depends on how you bind, filter and authenticate it. A memcached instance often holds session tokens, rendered pages, API responses and personal data copied from the database, and a reachable UDP listener can be abused to reflect traffic at third parties. Memcached gives operators clear controls for this: explicit listeners with -l, UDP off by default since 1.5.6, SASL on the binary protocol, token authentication on the text protocol, TLS since 1.5.13, and switches that turn off administrative commands. This guide covers how to combine them, how client credentials should be handled, what to monitor and how to roll changes out safely. It is for platform engineers, SREs and security architects running self-managed memcached, and it goes deeper than the general Database Security Guide.

This is an independent guide from NHI Mgmt Group, based on Memcached's public documentation as of November 2026. It is not sponsored or reviewed by the Memcached project. Product features change, so confirm settings against Memcached's current documentation.

Key takeaways

• Bind explicitly and keep 11211 private. Set -l to 127.0.0.1 or a private address (the compiled default listens on all interfaces; Debian and Ubuntu packages bind to 127.0.0.1), and firewall port 11211 from everything except application hosts.
• Keep UDP off. UDP has been disabled by default since 1.5.6 (released 27 February 2018). Pin -U 0 in your configuration so an old template or package cannot turn it back on.
• Add authentication as a second layer. Use SASL (-S, binary protocol) or the text protocol auth file (-Y) so a client on the right network still needs a credential.
• Encrypt with TLS where traffic crosses hosts. Build with --enable-tls, start with -Z, set ssl_min_version to TLS 1.2 or 1.3, and use ssl_verify_mode=2 for client certificates.
• Treat the cache as sensitive data. Separate instances per trust boundary, turn off flush_all and dump commands where not needed, and monitor connections and auth failures.

How identity and access work in Memcached

Memcached's access model is deliberately simple. Network reachability is the first control, and authentication, when enabled, gates the whole connection: once a client authenticates, it can use the commands the server allows on that instance. In practice NHI Mgmt Group treats the instance as the unit of isolation. Plan one instance (or one port with its own credentials) per application or trust boundary rather than sharing a cache between services with different data sensitivity.

Decision guidance: if your client library speaks the binary protocol, SASL is the established route. If you use the text or meta protocol, the -Y token file is the option the protocol documentation describes; check your client supports it and test it before relying on it. Where you already run an internal PKI, TLS with required client certificates gives strong mutual authentication and encryption together. Small deployments with the cache on the application host should simply use a Unix socket or loopback binding. The project notes that SASL helps but should not be your only defence, so in every case keep the network controls in place.

Admin roles and privileged access

In Memcached, administrative commands are available to any connected client when the server enables them, so access to the instance is the privileged path. Reduce that surface with startup flags and treat host access as the privileged path.

• Shutdown: the text protocol shutdown command is off by default and only enabled with -A / --enable-shutdown. Leave it off and stop the service through your init system.
• Flush: flush_all invalidates every item. Start with -F / --disable-flush-all if your application never needs it.
• Dumping: -X / --disable-dumping turns off stats cachedump, stats detail and lru_crawler metadump, which can list keys held in the cache.
• Watchers: the watch command streams internal logs (fetchers, mutations, evictions, connevents and others). It is useful for operators and also reveals key names, so restrict who can reach the instance.
• Host and configuration: the people who can edit /etc/memcached.conf or /etc/sysconfig/memcached, the SASL password database or the -Y file control authentication. Manage them through your privileged access process. See the Privileged Access Management Guide.
• Run as an unprivileged user: run the daemon under a dedicated service account, and keep the SASL password file and -Y file owned by and readable only by that account, as the SASL guide advises.

Integrations, API tokens and service accounts

Memcached's clients are almost always applications, so every memcached credential is a non-human identity.

• One credential per application: create a SASL user or a -Y entry per service so you can rotate and revoke one client without touching others. Some client libraries append @hostname to the SASL username, so check the exact name the server sees with verbose logging during setup.
• Store credentials in a secrets manager: inject them into the application at runtime rather than committing them to configuration repositories or container images. See the Secrets Management Guide.
• Rotate safely: add the new credential alongside the old one, roll the application, confirm auth_errors stays flat, then remove the old entry and restart memcached in a planned window, remembering that a restart clears the cache.
• Certificates: with TLS, keep server certificate and key paths stable and use the refresh_certs command to load renewed certificates without a restart; new connections use the new certificate. The stats output reports time_since_server_cert_refresh, which you can alert on.
• Cache content: session tokens, OAuth access tokens and API responses cached by the application are credentials in their own right. Set short expiry times, avoid caching long-lived secrets, and consider encrypting sensitive values in the application before storing them.

Logging and detection

Memcached keeps most of its operational evidence in counters rather than log files. Collect stats and stats settings on a schedule with your metrics agent, and send verbose output (-v) to the journal during troubleshooting only, since -vv prints client commands and responses.

Two ATT&CK techniques frame the detection work: Reflection Amplification (T1498.002), where a reachable UDP listener is used against third parties, and Exploit Public-Facing Application (T1190) for any service reachable from the internet. On the cloud side, add a scheduled check that no security group or firewall rule allows 11211 from 0.0.0.0/0. For upstream reflection defences, see the DDoS Protection Guide.

Metrics that show the controls work:

• Instances reachable on 11211 from the internet, TCP or UDP (target: zero).
• Percentage of instances with udpport set to 0 in stats settings (target: 100%).
• Percentage of instances requiring authentication or client certificates.
• Percentage of cross-host cache traffic carried over TLS.
• Days since each application credential was rotated, against policy.

Hardening baseline

Recommended startup flags

If one listener must stay plain text, for example a local health check, the notls: prefix on -l marks just that interface; keep it on loopback. Apply vendor security updates promptly and follow the project's advisories.

Phased rollout

1. Inventory: find every memcached process and container, its version and its startup flags. Run stats settings on each to record tcpport, udpport, auth_enabled_sasl and maxconns.
2. Close exposure: set -l, set -U 0 and apply firewall or security group rules for 11211. These changes rarely affect applications on the same network and remove the largest risk first.
3. Pilot authentication: enable SASL or -Y on a staging instance, update one client, check auth_errors and latency, then roll per application.
4. Add TLS: deploy certificates, enable -Z on a new port or instance, migrate clients, then require client certificates where your PKI supports it.
5. Reduce commands: add -F and -X once you confirm no tooling depends on them.
6. Roll back: each change is a startup flag, so keep the previous unit file or configuration in version control and revert by restarting. Plan for the cache being emptied on restart and warm it gradually.

Small and large estates

Small estates: when memcached runs on the same host as a single application, the simplest strong design is a Unix socket (-s) with a tight access mask (-a), or a loopback listener, plus -U 0. Network authentication and TLS add little when no traffic leaves the host, so spend the effort on host hardening and patching instead.

Large estates: when many application hosts share cache clusters, treat memcached like any other internal service. Put clusters in dedicated subnets, issue per-application credentials from your secrets platform, enable TLS with client certificates from your internal CA, and manage startup flags through configuration management so every node carries the same baseline. Feed stats settings into your configuration compliance tooling so drift on any node is flagged within a day, and include cache clusters in regular external exposure scans alongside databases.

Framework mapping

Common misconfigurations

• Relying on the compiled default listener: a source build or minimal container started without -l listens on all interfaces. Always pass -l and check with ss or netstat that only the intended addresses are bound.
• UDP enabled by a legacy template: configuration copied from older hosts may carry -U 11211. Pin -U 0 and alert when stats settings shows a non-zero udpport.
• Open cloud security groups: a rule allowing 11211 from anywhere, added for testing, stays in place. Scope rules to application subnets and review them automatically.
• One shared cache across trust boundaries: a cache shared by public and internal services lets either read the other's data. Use separate instances and credentials.
• Credentials in plain configuration: SASL passwords or -Y files readable by other users or committed to repositories. Restrict file permissions and load secrets at deploy time.
• TLS without client verification: enabling -Z but leaving ssl_verify_mode=0 encrypts traffic yet accepts any client. Combine TLS with SASL, -Y or required client certificates.

Practitioner checklist

• Pass -l with loopback or a private address on every instance, or use a Unix socket.
• Pin -U 0 and confirm udpport is 0 in stats settings.
• Restrict 11211 at the firewall and in cloud security groups to application hosts only.
• Enable SASL (-S) or text protocol auth (-Y) with one credential per application.
• Enable TLS (-Z) for cross-host traffic with ssl_min_version at TLS 1.2 or higher.
• Leave -A unset and add -F and -X where the application allows.
• Separate instances by application and data sensitivity, with short expiry for cached tokens.
• Collect stats and alert on auth_errors, connection spikes and settings drift.
• Run a supported release and apply vendor security updates promptly.

Standards and references

• Memcached: UDP DDoS advisory
• Memcached: TLS Support
• Memcached: SASL How To
• Memcached: Configuring Server
• Memcached: Protocol documentation (protocol.txt)
• Memcached: 1.5.6 Release Notes
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls

Related NHI Mgmt Group resources: Database Security Guide · Database Credential and Access Security Guide · Secrets Management Guide · DDoS Protection Guide