CVE-2025-48367: Redis Database DOS Vulnerability

CVE-2025-48367 Overview

Redis, a widely-used open source, in-memory database that persists on disk, is affected by a denial of service vulnerability. An unauthenticated connection can cause repeated IP protocol errors, leading to client starvation and, ultimately, a denial of service condition. This vulnerability impacts Redis installations that accept network connections, potentially disrupting critical caching and data storage operations.

Critical Impact

Unauthenticated attackers can exhaust server resources by triggering repeated IP protocol errors, starving legitimate clients and causing service outages in Redis deployments.

Affected Products

• Redis versions prior to 8.0.3
• Redis versions prior to 7.4.5
• Redis versions prior to 7.2.10
• Redis versions prior to 6.2.19

Discovery Timeline

• 2025-07-07 - CVE-2025-48367 published to NVD
• 2025-09-05 - Last updated in NVD database

Technical Details for CVE-2025-48367

Vulnerability Analysis

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The flaw exists in how Redis handles connection acceptance when network-level errors occur. When an unauthenticated connection triggers certain IP protocol errors during the accept() system call, the Redis server fails to properly handle these error conditions, causing it to stop accepting new connections rather than retrying.

The vulnerability is particularly concerning because it can be exploited without authentication. An attacker can remotely trigger the condition by establishing connections that generate specific network errors such as ECONNABORTED, ENETDOWN, EPROTO, or EHOSTUNREACH. When these errors occur, the server's connection acceptance loop terminates prematurely, leading to client starvation as legitimate connections cannot be established.

Root Cause

The root cause lies in Redis's network connection handling code within src/anet.c. Prior to the fix, when accept4() encountered certain error conditions from problematic connections, the server would treat these as fatal errors rather than transient conditions that could be safely retried. The server lacked proper differentiation between errors that indicate a problem with a specific incoming connection versus errors that indicate system-wide resource limitations.

Attack Vector

The attack can be performed remotely over the network without requiring any authentication or prior access to the Redis instance. An attacker sends malformed or specifically crafted network connections that trigger IP protocol errors during the connection acceptance phase. These errors cause the accept() call to fail in a way that prevents the server from continuing to accept new connections, effectively denying service to all clients attempting to connect.

// Security patch from src/anet.c - Retry accept() even if accepted connection reports an error
// Source: https://github.com/redis/redis/commit/bde62951accfc4bb0a516276fd0b4b307e140ce2

    if (stat(filepath, &sb) == -1) return 0;
    return S_ISFIFO(sb.st_mode);
}

/* This function must be called after accept4() fails. It returns 1 if 'err'
 * indicates accepted connection faced an error, and it's okay to continue
 * accepting next connection by calling accept4() again. Other errors either
 * indicate programming errors, e.g. calling accept() on a closed fd or indicate
 * a resource limit has been reached, e.g. -EMFILE, open fd limit has been
 * reached. In the latter case, caller might wait until resources are available.
 * See accept4() documentation for details. */
int anetAcceptFailureNeedsRetry(int err) {
    if (err == ECONNABORTED)
        return 1;

#if defined(__linux__)
    /* For details, see 'Error Handling' section on
     * https://man7.org/linux/man-pages/man2/accept.2.html */
    if (err == ENETDOWN || err == EPROTO || err == ENOPROTOOPT ||
        err == EHOSTDOWN || err == ENONET || err == EHOSTUNREACH ||
        err == EOPNOTSUPP || err == ENETUNREACH)
    {
        return 1;
    }
#endif
    return 0;
}

Detection Methods for CVE-2025-48367

Indicators of Compromise

• Sudden inability for legitimate clients to establish new Redis connections
• Elevated error rates in Redis server logs related to connection acceptance
• Unusual patterns of short-lived or failed connection attempts from specific IP addresses
• Redis service becoming unresponsive while the process remains running

Detection Strategies

• Monitor Redis connection metrics for sudden drops in accepted connections alongside increases in connection errors
• Implement network-level monitoring to detect anomalous connection patterns targeting Redis ports (default 6379)
• Configure alerting on Redis client timeout errors that may indicate server-side connection starvation
• Review Redis logs for repeated accept() failures or connection-related error messages

Monitoring Recommendations

• Enable Redis INFO command monitoring to track connected_clients and rejected_connections metrics
• Deploy network intrusion detection rules to identify potential DoS attack patterns against Redis services
• Set up connection rate limiting at the network or firewall level to mitigate high-volume connection attempts
• Implement Redis Sentinel or cluster monitoring to detect and respond to node availability issues

How to Mitigate CVE-2025-48367

Immediate Actions Required

• Upgrade Redis to patched versions: 8.0.3, 7.4.5, 7.2.10, or 6.2.19
• Implement network-level access controls to restrict Redis access to trusted IP addresses only
• Enable Redis authentication using requirepass configuration to add a layer of protection
• Consider placing Redis behind a firewall or VPN to limit network exposure

Patch Information

Redis has released security patches addressing this vulnerability across multiple version branches. The fix introduces the anetAcceptFailureNeedsRetry() function in src/anet.c that properly identifies transient connection errors and allows the server to continue accepting new connections. Patched versions are available:

• Redis 8.0.3
• Redis 7.4.5
• Redis 7.2.10
• Redis 6.2.19

For detailed information, refer to the GitHub Security Advisory GHSA-4q32-c38c-pwgq.

Workarounds

• Restrict network access to Redis using firewall rules allowing only trusted client IP addresses
• Deploy Redis behind a reverse proxy or load balancer that can absorb malicious connection attempts
• Implement connection rate limiting using iptables or similar network-level tools
• Use Redis in protected mode and bind to localhost if remote access is not required

# Configuration example - Restrict Redis network exposure
# In redis.conf:

# Bind Redis to specific interfaces only
bind 127.0.0.1 192.168.1.100

# Enable protected mode
protected-mode yes

# Require authentication
requirepass your_strong_password_here

# Set maximum number of clients
maxclients 10000