Redis is an in-memory data structure store

CVE-2026-23479 is a use-after-free in Redis unblock-client handling. In affected redis-server builds, when a blocked client is evicted while Redis is re-executing that blocked command, the error path mishandles a freed object and can be steered toward remote code execution in the Redis server process. Authoritative upstream ranges are broad: GitHub and NVD track >= 7.2.0, < 8.6.3, while Redis separately published fixed builds across supported lines, including OSS/CE 6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3 and Redis Software fixed builds.

The vendor/NVD framing of HIGH is technically fair in a lab because the impact is full process compromise. But in enterprise reality this is not an unauthenticated edge bug: the attacker needs Redis access first, then a fairly specific blocked-command/eviction condition, and there is no KEV listing, no public in-the-wild evidence, and a very low EPSS. That makes this a meaningful post-auth hardening issue, not something that should outrank unauthenticated perimeter RCEs.

Why this verdict

• Downgrade for attacker position: this requires authenticated remote access (PR:L) or an equivalently trusted internal foothold. In a 10,000-host estate, that means the attacker is usually already on the app path, not at the perimeter.
• Downgrade for exploit friction: the vulnerable path is not generic command execution; it needs a blocked client to be evicted during re-execution. GitHub's CVSS v4 AC:H aligns better with that operational reality than NVD's v3 AC:L.
• Downgrade for threat intel: no KEV, no confirmed in-the-wild exploitation, and very low EPSS (0.00103) all argue against emergency prioritization.
• Hold at MEDIUM, not LOW: successful exploitation is still full Redis-process compromise with likely RCE, and Redis often sits near high-value data, session material, and application secrets.
• Population adjustment: Redis is widely deployed, but many enterprise instances are internal-only, managed, or fronted by app tiers. Real exposed population is materially smaller than the raw install base.

Why not higher?

This is not an unauthenticated internet-edge bug. The chain assumes both reachability and low-privileged Redis access, then adds a specific runtime condition that is harder to satisfy reliably than the vendor's v3 score suggests. With no exploitation evidence, low EPSS, and no KEV listing, it does not justify HIGH or CRITICAL patch triage over active edge exposures.

Why not lower?

Once triggered, the outcome is not cosmetic: it can lead to remote code execution in a high-value infrastructure component. Redis commonly has access to sensitive in-memory data and may run on nodes that hold adjacent secrets or internal network reach, so the blast radius after success is still meaningful.

1. Fence Redis off the network — Restrict Redis to application subnets, private service networks, or cluster-local access only. This removes the easiest precondition for exploitation; for a MEDIUM finding there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but do this in the next routine network change if any instance is broader than intended.
2. Require strong ACLs and rotate app credentials — Because the exploit needs Redis access, tightening ACL users, removing overly broad command categories, and rotating shared passwords directly attacks the most important prerequisite. No mitigation SLA applies at MEDIUM, so schedule through normal secret-rotation and config governance rather than emergency change.
3. Move internet-facing or vendor-managed nodes to fixed builds first — If you do have directly exposed Redis, bastion-accessible admin Redis, or self-managed cloud cache nodes, those systems deserve the first patch wave because they collapse the reachability friction. Even at MEDIUM, use the early part of the remediation window for these outliers.
4. Harden the runtime around Redis — Run Redis as non-root, keep filesystem permissions tight, enforce container/AppArmor/SELinux/seccomp where applicable, and monitor for child-process execution. These controls do not remove the bug, but they reduce host-level payoff if memory corruption becomes code execution.
5. Alert on abnormal Redis command patterns and crashes — Track service restarts, segfaults, unusual blocked-client behavior, and unexpected command bursts from application identities. This is detective, not preventive, but it is the best way to catch a failed or partial exploitation attempt during the remediation window.

Run this on the target Redis host or inside the Redis container image you actually deploy. Invoke it as bash redis-cve-2026-23479-check.sh or bash redis-cve-2026-23479-check.sh /usr/local/bin/redis-server; no root is required if the redis-server binary is executable and in PATH. It checks upstream OSS/CE versions only and returns UNKNOWN for distro backports or custom vendor builds where version strings are ambiguous.

#!/usr/bin/env bash
# redis-cve-2026-23479-check.sh
# Check Redis OSS/CE version exposure for CVE-2026-23479.
# Outputs exactly one of: VULNERABLE, PATCHED, UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

REDIS_BIN="${1:-redis-server}"

if ! command -v "$REDIS_BIN" >/dev/null 2>&1; then
  if [ -x "$REDIS_BIN" ]; then
    :
  else
    echo "UNKNOWN"
    exit 2
  fi
fi

OUT="$($REDIS_BIN --version 2>/dev/null || true)"
if [ -z "$OUT" ]; then
  echo "UNKNOWN"
  exit 2
fi

# Typical output contains: Redis server v=7.2.14 sha=...
VER="$(printf '%s' "$OUT" | sed -n 's/.*v=\([0-9][0-9.]*\).*/\1/p')"
if [ -z "$VER" ]; then
  echo "UNKNOWN"
  exit 2
fi

# If the operator is using a distro backport/custom build, the package manager should be consulted.
# This script only makes an upstream OSS/CE call on clean semantic versions.
case "$VER" in
  *[!0-9.]*|*.*.*.*)
    echo "UNKNOWN"
    exit 2
    ;;
esac

normalize() {
  local IFS=.
  local a=($1)
  printf '%03d%03d%03d' "${a[0]:-0}" "${a[1]:-0}" "${a[2]:-0}"
}

ver_ge() { [ "$(normalize "$1")" -ge "$(normalize "$2")" ]; }
ver_lt() { [ "$(normalize "$1")" -lt "$(normalize "$2")" ]; }
ver_eq() { [ "$(normalize "$1")" -eq "$(normalize "$2")" ]; }

# Upstream fixed OSS/CE versions published by Redis.
PATCHED_SET="6.2.22 7.2.14 7.4.9 8.2.6 8.4.3 8.6.3"
for p in $PATCHED_SET; do
  if ver_eq "$VER" "$p"; then
    echo "PATCHED"
    exit 0
  fi
done

# Versions older than 7.2.0 are outside the primary upstream GHSA/NVD affected range.
# However, Redis advisory also shipped fixes for 6.2.x; if you're on 6.2.x but not 6.2.22,
# package backports/customizations can make a simple check unreliable.
if ver_lt "$VER" "6.2.0"; then
  echo "PATCHED"
  exit 0
fi

if ver_ge "$VER" "6.2.0" && ver_lt "$VER" "7.2.0"; then
  if ver_eq "$VER" "6.2.22"; then
    echo "PATCHED"
    exit 0
  else
    echo "UNKNOWN"
    exit 2
  fi
fi

# Primary affected window from NVD/GHSA: >= 7.2.0 and < 8.6.3,
# minus the explicit fixed point releases listed by Redis.
if ver_ge "$VER" "7.2.0" && ver_lt "$VER" "8.6.3"; then
  echo "VULNERABLE"
  exit 1
fi

if ver_ge "$VER" "8.6.3"; then
  echo "PATCHED"
  exit 0
fi

echo "UNKNOWN"
exit 2

Sources

1. Redis security advisory
2. GitHub Security Advisory GHSA-93m2-935m-8rj3
3. NVD CVE-2026-23479
4. Redis 8.6 release notes
5. Debian security tracker
6. Ubuntu OSV entry
7. SUSE CVE page
8. CISA Known Exploited Vulnerabilities Catalog