Valkey is a distributed key-value database

CVE-2026-21863 is an out-of-bounds read in Valkey clusterbus packet parsing that can terminate the valkey-server process when a malformed cluster PING extension is received. Authoritative records disagree slightly on the 9.0.x fix boundary, but the affected ranges consistently include pre-fix clustered Valkey branches around 7.2.x, 8.0.x, 8.1.x, and 9.0.x; the published fixed builds are 7.2.12, 8.0.7, 8.1.6, and either 9.0.2 per NVD/CPE text or 9.0.3 per the GitHub advisory and release notes.

The vendor-style AV:N/PR:N/UI:N label overstates enterprise urgency because it ignores where the vulnerable surface actually lives: the *cluster bus* port, not the normal client port. In real fleets this is usually node-to-node traffic on private networks, often firewalled, and the impact is process crash/DoS rather than code execution or data theft, so this scores as a downgrade from HIGH to MEDIUM despite the low-complexity packet trigger.

Why this verdict

• Downgrade for attacker position: the attacker needs network reachability to the cluster bus, which is typically private east-west infrastructure traffic rather than an internet-facing service.
• Downgrade for exposed population: only clustered Valkey nodes are in play; standalone deployments and fleets that never enable cluster mode are not reachable on this path.
• Downgrade for blast radius: the demonstrated impact is node crash / DoS, not code execution, data theft, or tenant escape.
• Downgrade for controls already expected in modern estates: NGFWs, security groups, Kubernetes network policies, and host firewalls should already restrict cluster-to-cluster ports to known peers.
• No upgrade from threat intel: no KEV listing, no primary-source active exploitation evidence, and the user-provided EPSS is very low.

Why not higher?

If this were on the standard client port or if there were active exploitation against internet-exposed caches, this could justify HIGH. But the prerequisite chain compounds downward: cluster mode, reachable cluster bus, and a narrow protocol path that normally sits behind internal ACLs.

Why not lower?

This is not just theoretical. Nodes explicitly accept cluster bus connections and reply to PING from untrusted peers, the bug is low-complexity once the port is reachable, and crashing a database node can still cause real customer-facing pain in sharded or latency-sensitive environments.

1. Lock down the cluster bus — Allow inbound cluster bus traffic only from known Valkey peer IPs or subnets using host firewall rules, security groups, or network ACLs. For a MEDIUM verdict there is no mitigation SLA, so do this in the next normal network-hardening change window if you cannot patch immediately.
2. Hunt for non-default cluster ports — Do not assume only 16379; find any configured cluster-port values in config management, container manifests, and service definitions. This closes the blind spot where scanners look only for the default port; again, no mitigation SLA applies at MEDIUM, but this belongs in routine exposure-reduction work.
3. Alert on non-peer connections — Create detections for inbound TCP sessions to cluster bus ports from IPs outside the cluster membership list. This gives you fast signal on recon or malformed packet testing while you work through normal remediation scheduling.
4. Validate HA restart behavior — Confirm systemd, orchestrator health checks, or container supervision restart the process cleanly and that failover does not thrash the cluster. This does not fix the bug, but it reduces operational blast radius while you move toward patching.

Run this on the target Valkey host as a normal user; root is only needed if you want package-manager fallback checks. Save it as check-cve-2026-21863.sh, then run bash check-cve-2026-21863.sh /usr/bin/valkey-server or just bash check-cve-2026-21863.sh to auto-discover the binary. It outputs VULNERABLE, PATCHED, or UNKNOWN and exits 0, 1, or 2 respectively.

#!/usr/bin/env bash
# check-cve-2026-21863.sh
# Determine likely exposure to CVE-2026-21863 on a Valkey host.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET="${1:-}"

find_bin() {
  if [[ -n "$TARGET" && -x "$TARGET" ]]; then
    echo "$TARGET"
    return 0
  fi
  for b in /usr/bin/valkey-server /usr/local/bin/valkey-server /bin/valkey-server; do
    [[ -x "$b" ]] && { echo "$b"; return 0; }
  done
  command -v valkey-server 2>/dev/null && return 0
  return 1
}

BIN="$(find_bin 2>/dev/null || true)"
if [[ -z "$BIN" ]]; then
  echo "UNKNOWN: valkey-server binary not found"
  exit 2
fi

RAWVER="$($BIN --version 2>/dev/null | head -n1)"
VER="$(printf '%s' "$RAWVER" | sed -n 's/.*v=\([0-9][0-9.]*\).*/\1/p')"

if [[ -z "$VER" ]]; then
  echo "UNKNOWN: could not parse version from: $RAWVER"
  exit 2
fi

IFS='.' read -r MAJ MIN PAT <<< "$VER"
MAJ="${MAJ:-0}"; MIN="${MIN:-0}"; PAT="${PAT:-0}"

ver_ge() {
  # usage: ver_ge a.b.c x.y.z
  local A B C X Y Z
  IFS='.' read -r A B C <<< "$1"
  IFS='.' read -r X Y Z <<< "$2"
  A=${A:-0}; B=${B:-0}; C=${C:-0}; X=${X:-0}; Y=${Y:-0}; Z=${Z:-0}
  if (( A > X )); then return 0; fi
  if (( A < X )); then return 1; fi
  if (( B > Y )); then return 0; fi
  if (( B < Y )); then return 1; fi
  (( C >= Z ))
}

ver_lt() {
  ! ver_ge "$1" "$2"
}

is_vuln=1
reason="not in affected branch"

# Affected ranges from NVD/GHSA, with special caution on 9.0.2 because sources disagree.
if ver_lt "$VER" "7.2.12"; then
  is_vuln=0
  reason="version is below 7.2.12"
elif ver_ge "$VER" "8.0.0" && ver_lt "$VER" "8.0.7"; then
  is_vuln=0
  reason="version is in 8.0.0-8.0.6"
elif ver_ge "$VER" "8.1.0" && ver_lt "$VER" "8.1.6"; then
  is_vuln=0
  reason="version is in 8.1.0-8.1.5"
elif ver_ge "$VER" "9.0.0" && ver_lt "$VER" "9.0.2"; then
  is_vuln=0
  reason="version is in 9.0.0-9.0.1"
elif [[ "$VER" == "9.0.2" ]]; then
  echo "UNKNOWN: version 9.0.2 sits in an advisory discrepancy (NVD suggests fixed; GHSA/release notes point to 9.0.3). Verify vendor/backport status."
  exit 2
fi

# Package manager hint for distro backports.
PKG_HINT=""
if command -v dpkg-query >/dev/null 2>&1; then
  PKG_HINT="$(dpkg-query -W -f='${Package} ${Version}\n' valkey 2>/dev/null || true)"
elif command -v rpm >/dev/null 2>&1; then
  PKG_HINT="$(rpm -q valkey 2>/dev/null || true)"
fi

if [[ -n "$PKG_HINT" ]]; then
  case "$PKG_HINT" in
    *deb13u2*|*8.1.1+dfsg1-3+deb13u2*|*ALAS2023* )
      echo "PATCHED: distro package appears backported/fixed ($PKG_HINT)"
      exit 0
      ;;
  esac
fi

if (( is_vuln == 0 )); then
  echo "VULNERABLE: parsed Valkey version $VER ($reason)"
  exit 1
fi

# Conservative patched logic.
if ver_ge "$VER" "9.0.3"; then
  echo "PATCHED: parsed Valkey version $VER"
  exit 0
elif ver_ge "$VER" "8.1.6" && ver_lt "$VER" "9.0.0"; then
  echo "PATCHED: parsed Valkey version $VER"
  exit 0
elif ver_ge "$VER" "8.0.7" && ver_lt "$VER" "8.1.0"; then
  echo "PATCHED: parsed Valkey version $VER"
  exit 0
elif ver_ge "$VER" "7.2.12" && ver_lt "$VER" "8.0.0"; then
  echo "PATCHED: parsed Valkey version $VER"
  exit 0
fi

echo "UNKNOWN: version $VER is outside known vulnerable ranges but package/backport status could not be confirmed"
exit 2

Sources

1. GitHub Security Advisory GHSA-c677-q3wr-gggq
2. Valkey fix commit 4169393
3. NVD CVE-2026-21863
4. Valkey cluster specification
5. Valkey security documentation
6. Valkey releases
7. Debian security tracker entry
8. Amazon Linux Security Center CVE entry