Redis NOAUTH / WRONGPASS authentication failures: ACL LOG and credential drift

Application logs report (error) NOAUTH Authentication required or (error) WRONGPASS invalid username-password pair or user is disabled. Connections drop, transactions abort, and previously working requests are rejected. Redis does not expose a per-client authentication failure counter in INFO stats; on Redis 6.2 and later, INFO errorstats counts aggregate WRONGPASS and NOAUTH errors, while ACL LOG (Redis 6.0+) is the only structured source that identifies the failing username and source address. On earlier versions, scrape the log file. Correlate the failure source, username, and timing to distinguish credential drift, misconfiguration, and brute-force probes.

What this means

NOAUTH means the client sent a command before authenticating, or continued sending commands after an AUTH failure left it in an unauthenticated state. WRONGPASS means the client presented credentials Redis could not validate.

On Redis 6.0+, the server supports per-user ACLs with AUTH username password. The implicit default user carries any legacy requirepass password. Pre-6.0 servers support only AUTH password.

ACL LOG is an in-memory ring buffer, not a persistent audit trail. The default length is 128 entries, configured by acllog-max-len. When the buffer fills, old entries drop. Under high-rate brute-force attempts, the log can rotate in seconds. Each entry aggregates identical failures within a 60-second window, incrementing a count field rather than logging every attempt.

Because there is no INFO counter for auth failures, operators often discover authentication problems through application errors. A slow credential drift, where one stale client reconnects periodically with an old password, may go unnoticed until the ACL LOG buffer has overwritten the evidence.

flowchart TD
    A[Clients report NOAUTH or WRONGPASS] --> B{Redis >= 6.0?}
    B -->|Yes| C[Run ACL LOG]
    B -->|No| D[Check redis log file for auth errors]
    C --> E{What does ACL LOG show?}
    E -->|reason=auth from app IPs| F[Credential drift or misconfiguration]
    E -->|reason=auth from unknown IPs| G[Brute-force or unauthorized probe]
    E -->|reason=command/key/channel| H[ACL permission issue, not auth]
    F --> I[Check ACL LIST and deployment timestamps]
    G --> J[Check network access controls and rate limits]

Common causes

Quick checks

These commands are read-only and safe to run on a live instance.

# Inspect recent authentication failures (Redis 6.0+)
redis-cli ACL LOG 10

# Verify configured users and their status
redis-cli ACL LIST

# Check current client connections and source addresses
redis-cli CLIENT LIST

# View general client connection counts
redis-cli INFO clients

# Check if legacy requirepass is set
redis-cli CONFIG GET requirepass

# Search Redis log file for auth errors (pre-6.0 or supplement to ACL LOG)
# Adjust the path to match your installation.
grep -i -E "wrongpass|noauth" /var/log/redis/redis-server.log

How to diagnose it

1. Confirm the error type. NOAUTH indicates the client never authenticated or was rejected and continued sending commands. WRONGPASS indicates the client presented invalid credentials. Check application logs for the exact reply.

2. Inspect ACL LOG for patterns. Run ACL LOG 50 and look for reason=auth. Note the username, client-info addr, and count fields. If the same application IP appears repeatedly with an old username, you have isolated a stale client.

3. Correlate with deployment events. Compare the first failure timestamp with application deployments, configuration management runs, or password rotation tickets. Credential drift usually begins within minutes of a rotation window closing.

4. Verify source IP legitimacy. If the addr field shows IPs outside application subnets, treat the traffic as unauthorized. If the IPs are legitimate but the username is unexpected, the client library may be defaulting to the default user instead of the intended ACL user.

5. Check for URI encoding issues. Passwords containing @, %, or ! must be URL-encoded in redis:// URIs. A parsing error can truncate the password before it reaches Redis, causing WRONGPASS even when the config appears correct. An unencoded @ is a common culprit because it terminates the userinfo section.

6. Validate ACL user state. Run ACL LIST and confirm the target user is active and has a password hash. If the user was disabled or the password removed during rotation, existing persistent connections fail on re-authentication.

Metrics and signals to monitor

Fixes

Credential drift during rotation

Appending a password with ACL SETUSER ... >password adds it to the user’s password list; it does not remove existing passwords. Persistent connections in pools or long-lived sockets continue to work until old passwords are explicitly removed with <oldpassword or resetpass.

To fix active drift, temporarily re-add the old password if you still have it, identify stale clients with CLIENT LIST or ACL LOG, restart those clients, then remove the old password. If you do not know the old password, be aware that clearing all passwords with resetpass will immediately break every connection for that user.

For future rotations, maintain a dual-password window: add the new password, deploy client updates, wait for all connections to roll over, then remove the old password.

Misconfigured client or URI encoding

Fix the application connection string. Ensure special characters in the password are URL-encoded (@ as %40, etc.). If using Redis 6.0+, confirm the client library supports AUTH username password and that you are not relying on the implicit default user when an explicit ACL user is required.

Brute-force or unauthorized probes

If unknown IPs are generating WRONGPASS entries, enforce network-layer restrictions first. Redis should not be reachable from untrusted networks. If the instance is exposed, enable protected-mode or bind to specific interfaces, ensure strong passwords are set, and disable the default user if all clients use named ACL users.

Immediate relief for connection bloat

If unauthenticated connections are accumulating and consuming resources, terminate them. This is disruptive to those clients but protects instance stability.

# List connections to identify stale clients
redis-cli CLIENT LIST

# Kill a specific connection by ID
redis-cli CLIENT KILL ID <client-id>

Prevention

• Replace requirepass with named ACL users. requirepass sets a password only on the implicit default user and does not provide per-client auditing.
• Poll ACL LOG via an external collector or monitoring agent. Because the buffer is only 128 entries by default, infrequent polling misses short spikes.
• URL-encode passwords in redis:// connection strings and store them in secret managers that validate encoding.
• After any password rotation, run ACL LOG 128 and verify that no legitimate application IPs continue to generate reason=auth entries.
• Restrict Redis to private subnets and require TLS in addition to authentication.

How Netdata helps

• Correlate connected_clients spikes with application error logs to determine whether a connection storm stems from auth failures or a separate leak.
• Alert on rejected_connections increases, which often accompany auth misconfigurations as clients retry aggressively.
• Track used_memory and used_memory_rss growth that may indicate client buffer accumulation during connection churn.
• Monitor application-level error rates alongside Redis metrics to scope impact during credential drift.

Related guides

• How Redis actually works in production: a mental model for operators
• Redis aof_last_write_status:err: AOF write failures and recovery
• Redis appendfsync always latency: durability vs throughput trade-offs
• Redis big keys: finding the giant key that blocks the event loop
• Redis blocked_clients growing: dead consumers vs healthy queues
• Redis BUSY Redis is busy running a script: blocking Lua and how to recover
• Redis Can’t save in background: fork: Cannot allocate memory - diagnosis and fix
• Redis client output buffer overflow: slow consumers and client-output-buffer-limit
• Redis cluster_slots_pfail > 0: impending node failure in a cluster
• Redis CLUSTERDOWN / cluster_state:fail: slot coverage and recovery
• Redis connected_clients climbing: connection leak detection
• Redis connected_slaves dropped: detecting replica disconnects on the primary