RedisTimeSeries is a time-series module for Redis

CVE-2026-25588 is a memory-safety bug in the RedisTimeSeries module's handling of serialized payloads passed through the Redis RESTORE command. The practical blast radius is narrower than generic Redis RCE headlines imply: the target must be running Redis with the RedisTimeSeries module loaded, and the vulnerable upstream module range is versions before 1.12.14, with vendor-fixed branches also called out as 1.10.24 and 1.8.23; Redis also published fixed OSS/CE builds 6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, and 8.6.3, plus Redis Software fixed builds 8.0.10-64, 7.22.2-79, 7.8.6-253, 7.4.6-279, and 7.2.4-153.

The vendor's HIGH label is technically defensible if you score pure impact in a lab, because successful exploitation can hand over the Redis process. In real enterprise operations, though, this is not an unauthenticated internet worm: it requires valid Redis access, permission to run a dangerous administrative command, and the specific module to be present, while EPSS is low and there is no KEV listing or vendor evidence of active exploitation, so the operational priority lands a notch lower at MEDIUM.

Why this verdict

• Start from 8.8 HIGH, then subtract for post-auth reality: the attacker must already hold valid Redis access, which usually means stolen creds, app compromise, or insider misuse rather than clean-sheet internet exploitation.
• Subtract again for command-level privilege: needing RESTORE permission is not cosmetic; mature Redis ACLs often deny risky import/admin commands to application users, and the vendor workaround exists precisely because this breaks the chain.
• Subtract again for module gating and population narrowing: only Redis servers with RedisTimeSeries loaded are in scope, and RedisTimeSeries is a subset of Redis deployments; Redis Cloud is already fixed and generic Redis scan counts overstate this module's reachable population.
• Subtract for current threat intel: no KEV listing, no vendor-confirmed exploitation, no authoritative public PoC in reviewed sources, and a low EPSS all argue against treating this as emergency-wide incident response.
• Keep it above LOW because the impact is still ugly: if an attacker already sits in the right seat, this can become code execution in the Redis process and lead to data theft, tampering, or service loss.

Why not higher?

A higher rating would fit an unauthenticated or broadly reachable exploit path. This one is gated by authentication, by a dangerous command privilege, and by the presence of a specific optional module, so it behaves like a post-compromise amplifier rather than a universal external break-in. The lack of active exploitation evidence and low EPSS reinforce the downgrade.

Why not lower?

This is still memory corruption with plausible RCE in a high-value data service. Once an attacker has the needed access, the impact ceiling is full compromise of the Redis process, so writing it off as hygiene would understate the consequence.

1. Deny RESTORE to app identities — Use Redis ACLs to remove RESTORE from every service account that does not explicitly need import/restore workflows. For a MEDIUM noisgate verdict there is no mitigation SLA, so treat this as immediate hardening work while you schedule patching inside the 365-day remediation window.
2. Fence Redis behind trusted networks only — Restrict source IPs and service-to-service paths so only known application tiers and admin jump points can reach Redis. This reduces the odds that stolen cloud creds, developer laptops, or adjacent workloads can reach the vulnerable code path; again, there is no mitigation SLA for MEDIUM, but this is worth doing now because it cuts exposure for more than this CVE.
3. Inventory Redis modules explicitly — Update your CMDB, discovery jobs, or config scans to record whether RedisTimeSeries is loaded and which branch it is on. That lets you avoid wasting cycles on plain Redis nodes that are not affected and focus remediation within the 365-day window on the systems that actually carry the module.
4. Alert on RESTORE usage — Create detections for RESTORE execution by non-admin identities and for any sudden spike in data-import style commands. This will not fix the bug, but it is a strong tripwire for attempted exploitation and high-risk misuse while you work through remediation.

Run this from an auditor workstation or admin jump host that can reach the Redis service, or directly on the target host if that's easier. Invoke it as ./check_redistimeseries_cve_2026_25588.sh 10.0.12.34 6379 'SuperSecret'; it needs redis-cli installed and a Redis credential allowed to run MODULE LIST.

#!/usr/bin/env bash
# check_redistimeseries_cve_2026_25588.sh
# Exit codes:
#   0 = PATCHED / not affected
#   1 = VULNERABLE
#   2 = UNKNOWN / error

set -u

HOST="${1:-127.0.0.1}"
PORT="${2:-6379}"
PASS="${3:-}"

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

REDIS_CMD=(redis-cli -h "$HOST" -p "$PORT" --raw)
if [ -n "$PASS" ]; then
  REDIS_CMD+=( -a "$PASS" )
fi

OUTPUT="$(${REDIS_CMD[@]} MODULE LIST 2>&1)"
RC=$?
if [ $RC -ne 0 ]; then
  echo "UNKNOWN - failed to query Redis: $OUTPUT"
  exit 2
fi

if echo "$OUTPUT" | grep -qiE 'NOAUTH|WRONGPASS|AUTH failed|DENIED'; then
  echo "UNKNOWN - authentication/authorization failed for MODULE LIST"
  exit 2
fi

if [ -z "$OUTPUT" ]; then
  echo "UNKNOWN - empty response from MODULE LIST"
  exit 2
fi

# Parse raw MODULE LIST output. In --raw mode it is typically key/value lines per module.
current_name=""
current_ver=""
found_name=""
found_ver=""
expect=""

while IFS= read -r line; do
  case "$line" in
    name)
      expect="name"
      ;;
    ver)
      expect="ver"
      ;;
    *)
      if [ "$expect" = "name" ]; then
        current_name="$line"
        expect=""
      elif [ "$expect" = "ver" ]; then
        current_ver="$line"
        expect=""
        case "$current_name" in
          timeseries|RedisTimeSeries|redistimeseries)
            found_name="$current_name"
            found_ver="$current_ver"
            ;;
        esac
      fi
      ;;
  esac
done <<< "$OUTPUT"

if [ -z "$found_name" ]; then
  echo "PATCHED - RedisTimeSeries module not loaded on this Redis instance"
  exit 0
fi

if ! [[ "$found_ver" =~ ^[0-9]+$ ]]; then
  echo "UNKNOWN - could not parse RedisTimeSeries module version: $found_ver"
  exit 2
fi

# Redis modules often encode semver as integer, e.g. 1.12.14 -> 11214.
# Vendor fixed branches cited by Redis: 1.12.14, 1.10.24, 1.8.23.
ver="$found_ver"

is_patched=1
if [ "$ver" -ge 11214 ]; then
  is_patched=0
elif [ "$ver" -ge 11024 ] && [ "$ver" -lt 11100 ]; then
  is_patched=0
elif [ "$ver" -ge 10823 ] && [ "$ver" -lt 10900 ]; then
  is_patched=0
fi

if [ $is_patched -eq 0 ]; then
  echo "PATCHED - RedisTimeSeries module version integer $ver is on a cited fixed branch"
  exit 0
fi

echo "VULNERABLE - RedisTimeSeries module version integer $ver is below cited fixed branches (1.12.14 / 1.10.24 / 1.8.23)"
exit 1

Sources

1. NVD CVE-2026-25588
2. GitHub Security Advisory GHSA-7jwr-g5qv-w3gw
3. Redis security advisory for May 5, 2026 issues
4. RedisTimeSeries release v1.12.14
5. Ubuntu CVE tracker entry
6. Docker Scout / Bitnami advisory view
7. Censys analysis of exposed Redis services
8. CISA Known Exploited Vulnerabilities Catalog