Valkey is a distributed key-value database

CVE-2025-67733 is a RESP response-stream injection flaw in Valkey's Lua error path. In affected releases—up to 7.2.11, 8.0.6, 8.1.5, and 9.0.1—an attacker who can execute scripting commands can craft an error containing control bytes so leftover data is interpreted as a later reply on the same connection. Upstream fixed it in 7.2.12, 8.0.7, 8.1.6, and 9.0.2 on February 23, 2026.

GitHub's CNA score of 8.5 is technically defensible in a lab, but it overstates most enterprise reality. The decisive friction is that exploitation usually requires more than raw network reachability: the attacker needs authenticated or application-mediated access to EVAL/FCALL, and the environment has to reuse a Valkey connection across trust boundaries so another operation consumes the poisoned reply. That is materially narrower than a normal unauthenticated remote service exploit, so this gets downgraded to MEDIUM.

Why this verdict

• Start at the vendor's 8.5 because a network-reachable, low-complexity bug in a common data tier deserves attention on paper
• Down for attacker position: exploitation generally requires authenticated Valkey access or an application path that exposes EVAL/FCALL, which implies prior trust or a design flaw upstream of Valkey
• Down for population reachability: many enterprises keep Valkey internal, firewalled, and behind app mediation, so the exposed population is much smaller than the CVSS baseline assumes
• Down for chain fragility: the exploit needs connection reuse across security contexts so a victim consumes the poisoned reply; that dependency knocks out many well-behaved deployments
• Back up slightly because PoC is public: once the prerequisites are present, weaponization is practical and integrity impact is real

Why not higher?

There is no host compromise here: no RCE, no auth bypass, no privilege escalation, and no broad server-side data theft primitive by itself. The exploit chain is materially narrower than the vendor score suggests because it depends on both scripting access and a vulnerable connection-sharing pattern.

Why not lower?

This is still not harmless. If your application lets low-trust users touch Valkey scripting and reuses a backend connection, a real attacker can tamper with other users' replies or trigger application instability with off-the-shelf PoC code.

1. Remove scripting from low-trust ACLs — Deny @scripting or explicitly block EVAL, EVALSHA, FCALL, and FUNCTION LOAD for any account used by applications or users that do not need programmability. For a MEDIUM verdict there is no noisgate mitigation SLA; deploy this now where feasible, otherwise go straight to the remediation window.
2. Fence Valkey behind internal-only network policy — Restrict port 6379 to trusted app tiers and admin networks only, and verify there is no direct internet path. Again, there is no noisgate mitigation SLA for MEDIUM, but external exposure is the one condition most likely to turn this from niche to operationally painful.
3. Separate trust domains at the connection layer — Do not let attacker-controlled and victim traffic share the same backend Valkey connection or pool when scripting is in play. Use per-service or per-tenant pools and drop sockets on protocol or Lua error anomalies; do this during the normal remediation window if you cannot harden it immediately.
4. Audit for unexpected scripting use — Inventory where your estate actually uses Lua scripts or Valkey functions, because environments that never use them can usually shut the feature off for app identities with minimal breakage. That sharply reduces reachable exploit surface without waiting for a code release.

Run this on the target Valkey host or from an auditor box that has valkey-cli access to the instance. Invoke it as ./check_cve_2025_67733.sh 127.0.0.1 6379 or ./check_cve_2025_67733.sh valkey01.example.com 6379 'password'; no root is required unless you rely on local package-manager fallback.

#!/usr/bin/env bash
# noisgate verifier for CVE-2025-67733
# Usage: ./check_cve_2025_67733.sh [host] [port] [password]
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

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

ver_ge() {
  # returns success if $1 >= $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$2" ]
}

trim_version() {
  echo "$1" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1 || true
}

get_from_cli() {
  if ! command -v valkey-cli >/dev/null 2>&1; then
    return 1
  fi

  local auth_args=()
  if [ -n "$PASS" ]; then
    auth_args=(-a "$PASS")
  fi

  local info out
  if out=$(valkey-cli -h "$HOST" -p "$PORT" "${auth_args[@]}" --raw INFO server 2>/dev/null); then
    info="$out"
    VERSION=$(echo "$info" | awk -F: '/^valkey_version:/{print $2}' | tr -d '\r' | head -n1)
    if [ -z "$VERSION" ]; then
      VERSION=$(echo "$info" | awk -F: '/^redis_version:/{print $2}' | tr -d '\r' | head -n1)
    fi
    VERSION=$(trim_version "$VERSION")
    [ -n "$VERSION" ]
    return 0
  fi

  return 1
}

get_from_server_binary() {
  if ! command -v valkey-server >/dev/null 2>&1; then
    return 1
  fi

  local out
  out=$(valkey-server --version 2>/dev/null || true)
  VERSION=$(trim_version "$out")
  [ -n "$VERSION" ]
}

get_from_packages() {
  if command -v dpkg-query >/dev/null 2>&1; then
    VERSION=$(dpkg-query -W -f='${Version}\n' valkey-server 2>/dev/null | head -n1 || true)
    VERSION=$(trim_version "$VERSION")
    [ -n "$VERSION" ] && return 0

    VERSION=$(dpkg-query -W -f='${Version}\n' valkey 2>/dev/null | head -n1 || true)
    VERSION=$(trim_version "$VERSION")
    [ -n "$VERSION" ] && return 0
  fi

  if command -v rpm >/dev/null 2>&1; then
    VERSION=$(rpm -q --qf '%{VERSION}\n' valkey 2>/dev/null | head -n1 || true)
    VERSION=$(trim_version "$VERSION")
    [ -n "$VERSION" ] && return 0
  fi

  return 1
}

is_vulnerable() {
  local v="$1"

  # Affected upstream ranges:
  #   < 7.2.12
  #   8.0.0 - 8.0.6
  #   8.1.0 - 8.1.5
  #   9.0.0 - 9.0.1

  if ver_ge "$v" "9.0.0" && ! ver_ge "$v" "9.0.2"; then
    return 0
  fi

  if ver_ge "$v" "8.1.0" && ! ver_ge "$v" "8.1.6"; then
    return 0
  fi

  if ver_ge "$v" "8.0.0" && ! ver_ge "$v" "8.0.7"; then
    return 0
  fi

  if ! ver_ge "$v" "7.2.12"; then
    return 0
  fi

  return 1
}

main() {
  get_from_cli || get_from_server_binary || get_from_packages || true

  if [ -z "$VERSION" ]; then
    echo "UNKNOWN - unable to determine Valkey version"
    exit 2
  fi

  if is_vulnerable "$VERSION"; then
    echo "VULNERABLE - detected version $VERSION"
    exit 1
  else
    echo "PATCHED - detected version $VERSION"
    exit 0
  fi
}

main "$@"

Sources

1. NVD CVE record
2. GitHub Security Advisory
3. Public PoC by JYlab
4. Valkey security guidance
5. CISA KEV catalog
6. Ubuntu USN-8106-1
7. Debian DSA-6198-1
8. SUSE CVE page