Memcached auth_errors: SASL failures, brute force, and the no-auth default

Two counters, present since memcached 1.4.4, are the only native signal the daemon gives you about authentication activity: auth_cmds and auth_errors. They count attempts and failures. They do not tell you who attempted, from where, or whether authentication is even enforced.

The critical interpretation rule: if authentication is not enabled (no -S for SASL, no -Y for ASCII token auth), both counters read zero forever. Zero does not mean “no unauthorized access.” It means “nothing is enforced.” A cache that reports zero auth_cmds can still be wide open to every host that can reach port 11211.

What this means

When auth is enabled and auth_errors is non-zero, someone connected with credentials memcached rejected. A failure ratio above 10% (auth_errors / auth_cmds) is abnormal. A sustained failure rate above roughly 10 per second suggests brute force or credential stuffing. Lower rates from a known client fleet more often point to a misconfigured deploy: stale credentials, a rotated secret that did not propagate, or a client speaking the wrong protocol for the configured auth mode.

When auth is not enabled, the counters are silent. This is the more common production state, and the one that demands the most careful reasoning. Memcached was designed for trusted internal networks. The default posture is that anyone who can open a TCP connection to the port can read and write any key, issue flush_all, and enumerate the keyspace. Authentication is opt-in.

SASL (-S) is the mature option, but it requires the binary protocol, which creates tension with the ASCII-based meta commands introduced experimentally in 1.5.19. The binary protocol implementation is deprecated as of 1.6.0, although it remains in the source. ASCII token auth (-Y authfile) was introduced in 1.5.15 and is still marked experimental in its release notes. The practical effect is that real authentication in memcached is coupled to protocol choices you may not want to make for other reasons.

Common causes

The last row refers to a reported bypass where a proto[negotiating] listener can route ASCII traffic around the auth gate even when -Y is set globally. Memcached 1.6.43 fixes this by making negotiating ports ASCII-only when ASCII token auth is enabled.

Quick checks

All read-only and safe during an incident.

# Inspect auth counters (cumulative since process start)
echo "stats" | nc -q1 localhost 11211 | grep -E "STAT auth_(cmds|errors)"

# Confirm auth flags on the running process
ps -o args= -p "$(pgrep -x memcached)" | tr ' ' '\n' | grep -E '^-S|^-Y|^-o'

# Confirm UDP is disabled (default since 1.5.6; CVE-2018-1000115 amplification if exposed)
echo "stats settings" | nc -q1 localhost 11211 | grep "STAT udpport"

# List connection sources to the memcached port
ss -tnp | grep ":11211" | awk '{print $5}' | sed 's/:[0-9]*$//' | sort | uniq -c | sort -rn

# Check version; also confirms the process answers commands, not just accepts TCP
echo "version" | nc -w 2 localhost 11211

How to diagnose it

flowchart td
    A["auth_errors > 0?"] -->|"yes"| B["Auth is enforced.
Failures are real."]
    A -->|"no"| C["auth_cmds > 0?"]
    C -->|"yes"| D["Auth enforced.
No current failures."]
    C -->|"no"| E["-S or -Y in process args?"]
    E -->|"no"| F["Auth NOT enforced.
Network is the only gate."]
    E -->|"yes"| G["Auth enabled but no attempts yet.
Audit listener configs."]
    B --> H["Find source via ss/netstat.
Memcached logs no client IP."]
    F --> I["Restrict network path now.
Then decide on -S or -Y."]

1. Confirm whether auth is actually enforced. Before interpreting any counter, inspect the process command line for -S or -Y. If neither is present, the counters are inert by design, and your real problem is network exposure, not failed logins.

2. Compute the failure ratio and the rate. Sample auth_cmds and auth_errors twice with a known interval. A ratio above 10% is abnormal. A sustained auth_errors rate above 10 per second is consistent with brute force or credential stuffing rather than a deploy blip.

3. Find the source at the OS layer. Memcached does not log the client IP for authentication failures. You must correlate the failure window with connection-level telemetry. ss -tnp on the memcached host, sampled during the failure burst, is the fastest path to a source IP distribution.

4. Rule out protocol mismatch. SASL requires the binary protocol. A client configured for ASCII text against a SASL-protected server will not authenticate cleanly. PHP clients in particular require Memcached::OPT_BINARY_PROTOCOL set to true before Memcached::setSaslAuthData() will work without a warning. Check client library configuration, not just the daemon.

5. Check version-specific caveats. Several auth-related issues are version-bound. SASL combined with UDP was a bypass vector until memcached 1.5.20 refused to start with both enabled. A timing side-channel in the SASL password database (CVE-2026-47783) was addressed in 1.6.42. Historical SASL issues include an auth bypass fixed in 1.4.17 (CVE-2013-7239) and a remote code execution fixed in 1.4.32 (CVE-2016-8706). If your version is old, the counters may be trustworthy while the underlying mechanism is not.

Metrics and signals to monitor

Fixes

Stale credentials after a deploy or rotation

If auth_errors tracks a deploy or rotation timestamp, the fix is on the client side. Push corrected credentials, then watch auth_errors flatten while auth_cmds continues. Do not disable auth to unblock the deploy; that turns a credential problem into an exposure problem.

Brute force or credential stuffing from untrusted sources

Memcached has no built-in rate limiting or per-IP ban list for auth failures. The defense lives at the network layer. Restrict the port with firewall rules to expected client CIDRs. If you cannot constrain sources, move memcached behind a private network rather than hardening auth in place.

Client speaking the wrong protocol

SASL requires the binary protocol. If your clients are on ASCII text, either switch them to binary or move to the experimental -Y ASCII token auth. Do not mix: a fleet half on binary SASL and half on ASCII against the same instance will produce a steady trickle of auth_errors that looks like an attack but is a configuration split.

Auth not enabled and the port is exposed

This is the highest-severity finding even though no counter moves. If -S and -Y are both absent, the counters read zero indefinitely while every reachable host has full read and write access. The immediate fix is network-level: bind to an internal interface with -l, firewall the port, and disable UDP. Then decide whether to enable auth or rely on network segmentation.

Listener downgrade with proto[negotiating]

If you run -Y globally but configure a listener with proto[negotiating], ASCII traffic can bypass the auth gate on that listener. Align listener protocols with the auth mode or remove the negotiating listener. Confirm against your version whether the upstream bypass is patched before relying on configuration alone.

Prevention

• Treat zero auth_cmds as a finding, not a clean bill of health. Alert on the absence of auth flags in the process args when the port is reachable beyond the local host. The counters cannot tell you auth is missing; only the configuration can.
• Attribute failures at the network layer. Because memcached logs no client IP for auth failures, instrument ss or conntrack sampling so that an auth_errors burst can be correlated to a source distribution after the fact.
• Pin client and daemon protocol choices together. SASL and binary are coupled. Document which clients use which protocol so a deploy does not silently flip a client off binary and break auth.
• Track the version. Several auth issues are fixed only in specific releases. A monitoring rule that flags instances old enough to carry known SASL issues gives early warning that the auth mechanism itself may have weaknesses.
• Disable UDP everywhere. UDP amplification is a separate risk from auth, but compounds any exposure. Confirm udpport is zero on every instance.

How Netdata helps

• Per-second auth_cmds and auth_errors rates let you see a brute-force burst within seconds rather than waiting for a polled counter to delta.
• Anomaly detection on the failure rate surfaces credential-stuffing patterns that do not trip a fixed threshold but deviate sharply from the baseline.
• Correlation with connection telemetry on the host means an auth_errors spike can be read alongside the source IP distribution from the same window, compensating for memcached’s lack of client IP logging.
• Composite alerts can check configuration, not just counters. Pairing auth_errors with the presence of -S or -Y in the process args distinguishes “auth is working and rejecting bad actors” from “auth is not enabled and the counters are inert.”
• Version tracking across the fleet flags instances old enough to carry known SASL issues, so the auth mechanism itself is part of the risk picture.

Related guides

• Memcached cache stampede: a hot key expires and the backend takes the hit
• Memcached evicted_unfetched and expired_unfetched: caching data nobody ever reads
• Memcached cas_badval climbing: check-and-set contention and lost updates
• Memcached command rate anomalies: cmd_get and cmd_set spikes and sudden drops
• Memcached conn_yields rising: one client’s pipeline starving the others
• Memcached connection churn: total_connections racing and TIME_WAIT buildup
• Memcached curr_connections climbing: connection leaks and missing pooling
• Memcached connection limit reached: accepting_conns=0 and clients being refused
• Memcached connection refused: telling a dead process from a hung or full one
• Memcached CPU saturation: the per-thread ceiling that aggregate graphs hide
• Memcached evicted_time low: distinguishing healthy turnover from cache thrash
• Memcached eviction cascade: when a full cache overloads the backend