Redis is an in-memory data structure store

CVE-2026-23631 is a Redis Lua use-after-free in the master-replica synchronization path. An authenticated attacker can abuse SLAVEOF/replication behavior during Lua execution to free the Lua engine and then keep executing against freed memory, which can end in remote code execution on the replica. Redis says the issue exists in versions with Lua scripting, but the practical risk centers on replicas where replica-read-only is disabled or can be disabled; Redis shipped fixes on 2026-05-05 in OSS/CE 6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, and 8.6.3.

The scary part is real: there is a public exploit and a detailed write-up from Yoni Sherez published on 2026-06-02. But the headline 8.1 HIGH overstates enterprise reality because this is not unauthenticated internet RCE; it needs authenticated Redis access, Lua-capable permissions, replication/control-plane actions, and a replica deployment shape that narrows the exposed population hard. Redis/GitHub's own published severity is Moderate 6.1, and that is much closer to how a 10,000-host defender should triage it.

Why this verdict

• Downgrade from the 8.1 baseline: NVD's v3.1 score treats this like any low-privileged network user can cash out on impact. In practice, the attacker needs authenticated Redis access and usually privileged command scope across scripting and replication control.
• Replica-only deployment narrowing: The bug matters operationally on replicas where replica-read-only is disabled or can be disabled. That is a sharply smaller slice of Redis estates than 'all Redis with Lua' makes it sound.
• Public exploit raises the floor: Yoni Sherez published a full exploit and root-cause walk-through on 2026-06-02, so defenders should not write this off as theoretical even though the population is narrow.

Why not higher?

This is not pre-auth internet RCE, and it is not a clean one-command exploit against the average Redis node. Each prerequisite compounds downward pressure: attacker position, authenticated access, dangerous ACL scope, replication manipulation, and a writable replica are all real-world filters that exclude most enterprise deployments.

Why not lower?

The impact is still host-level code execution when the chain lands, and there is public exploit code rather than just an abstract memory-corruption note. If you run shared-service Redis, multi-tenant platforms, or any externally reachable/admin-accessible replicas, this can become a very ugly post-compromise accelerator.

1. Strip dangerous ACL rights — Remove or tightly gate @admin, CONFIG, SLAVEOF/REPLICAOF, and Lua-capable permissions from application identities. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but do this immediately on shared or internet-adjacent Redis tiers because it removes the exploit's key prerequisite.
2. Keep replicas read-only — Enforce replica-read-only yes and alert on any change away from it. There is no mitigation SLA for MEDIUM, but this is the cleanest temporary brake because the published chain specifically wants writable replica behavior.
3. Disable Lua where unused — If your estate does not rely on EVAL, FUNCTION LOAD, or FCALL, deny those commands or disable the feature path operationally. With no mitigation SLA for MEDIUM, treat this as a hygiene change now and complete vendor remediation inside the 365-day window.
4. Fence Redis off untrusted networks — Redis should sit on private networks with explicit allowlists; exposed admin paths turn a narrow post-auth flaw into a much more reachable one. Again, there is no mitigation SLA here, but exposed replicas deserve acceleration outside the normal window.
5. Alert on replication drift — Generate detections for SLAVEOF/REPLICAOF, replica peer changes, slow-script timeouts, and CONFIG SET replica-read-only no. This does not fix the bug, but it catches the exact control-plane activity the exploit needs while you work through remediation within 365 days.

Run this on the target Redis host or from an auditor box that already has redis-cli network access to the instance. Invoke it as ./check-cve-2026-23631.sh 127.0.0.1 6379 (or set REDISCLI_AUTH first if auth is required); no root is needed, but you do need permission to query INFO and CONFIG GET.

#!/usr/bin/env bash
# check-cve-2026-23631.sh
# Determine practical exposure to CVE-2026-23631 on a Redis instance.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

HOST="${1:-127.0.0.1}"
PORT="${2:-6379}"
REDIS_CLI_BIN="${REDIS_CLI_BIN:-redis-cli}"

if ! command -v "$REDIS_CLI_BIN" >/dev/null 2>&1; then
  echo "UNKNOWN - redis-cli not found"
  exit 2
fi

redis_raw() {
  "$REDIS_CLI_BIN" --raw -h "$HOST" -p "$PORT" "$@" 2>/dev/null
}

version_ge() {
  # usage: version_ge current required
  [ "$(printf '%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]
}

info_server="$(redis_raw INFO server)"
if [ -z "$info_server" ]; then
  echo "UNKNOWN - unable to query INFO server on ${HOST}:${PORT}"
  exit 2
fi

version="$(printf '%s\n' "$info_server" | awk -F: '/^redis_version:/{gsub(/\r/,"",$2); print $2; exit}')"
if [ -z "$version" ]; then
  echo "UNKNOWN - could not determine redis_version"
  exit 2
fi

info_repl="$(redis_raw INFO replication)"
role="$(printf '%s\n' "$info_repl" | awk -F: '/^role:/{gsub(/\r/,"",$2); print $2; exit}')"

cfg_ro="$(redis_raw CONFIG GET replica-read-only | tail -n1 | tr -d '\r')"
if [ -z "$cfg_ro" ] || [ "$cfg_ro" = "replica-read-only" ]; then
  cfg_ro="$(redis_raw CONFIG GET slave-read-only | tail -n1 | tr -d '\r')"
fi

is_patched_branch=0
case "$version" in
  6.2.*)
    if version_ge "$version" "6.2.22"; then is_patched_branch=1; fi
    ;;
  7.2.*)
    if version_ge "$version" "7.2.14"; then is_patched_branch=1; fi
    ;;
  7.4.*)
    if version_ge "$version" "7.4.9"; then is_patched_branch=1; fi
    ;;
  8.2.*)
    if version_ge "$version" "8.2.6"; then is_patched_branch=1; fi
    ;;
  8.4.*)
    if version_ge "$version" "8.4.3"; then is_patched_branch=1; fi
    ;;
  8.6.*)
    if version_ge "$version" "8.6.3"; then is_patched_branch=1; fi
    ;;
  *)
    # Public vendor guidance is clearest on the maintained branches above.
    # For other versions/builds, avoid a false assertion.
    echo "UNKNOWN - unrecognized or non-standard Redis version '$version'"
    exit 2
    ;;
esac

if [ "$is_patched_branch" -eq 1 ]; then
  echo "PATCHED - Redis $version is at or above a published fixed version"
  exit 0
fi

# Practical exposure test:
# This CVE is operationally relevant on replicas where replica-read-only is disabled.
if [ "$role" = "slave" ] || [ "$role" = "replica" ]; then
  if [ "$cfg_ro" = "no" ]; then
    echo "VULNERABLE - Redis $version is an unpatched writable replica (replica-read-only=no)"
    exit 1
  fi

  if [ "$cfg_ro" = "yes" ]; then
    echo "UNKNOWN - Redis $version is unpatched but currently read-only; exploitability depends on whether an attacker can change replica-read-only or replication state"
    exit 2
  fi

  echo "UNKNOWN - Redis $version is unpatched replica; could not read replica-read-only setting"
  exit 2
fi

echo "UNKNOWN - Redis $version is unpatched, but this check did not observe a runtime replica condition; review ACLs for SLAVEOF/CONFIG and patch"
exit 2

Sources

1. Redis security advisory
2. GitHub Security Advisory GHSA-8ghh-qpmp-7826
3. NVD CVE-2026-23631
4. ZeroDay.cloud write-up by Yoni Sherez
5. Public exploit repository
6. CISA Known Exploited Vulnerabilities Catalog
7. SUSE CVE page with fixed package versions
8. Censys Redis exposure research