← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-25589 · CWE-122 · Disclosed 2026-05-05

RedisBloom is a probabilistic data structures module for Redis

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a loaded nail gun locked in the maintenance closet, not a sniper rifle pointed at the internet

CVE-2026-25589 is a memory-corruption flaw in how RedisBloom deserializes data supplied through Redis RESTORE. In plain English: if an attacker can log into Redis, reach a node with RedisBloom loaded, and run RESTORE, they can feed it a malicious serialized payload that may crash redis-server or potentially execute code in the Redis process. GitHub's advisory says all RedisBloom versions are affected; Redis later published fixed standalone module builds 2.4.23, 2.6.28, and 2.8.20, and fixed Redis OSS/CE builds 6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, and 8.6.3.

The vendor's HIGH label makes sense in a lab because the impact is full process compromise, but it overshoots reality for most enterprises. This is not pre-auth internet spray-and-pray: it requires authenticated Redis access, permission to execute RESTORE, and the RedisBloom code path. Those are meaningful friction points, and the tiny EPSS plus no KEV listing tells you the same story: nasty if you already have a foothold, but not the kind of bug that should reorder a 10,000-host patch queue by itself.

"Serious bug, but it needs authenticated Redis access, RESTORE rights, and RedisBloom in the path."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Reach Redis and authenticate with a usable account

The attacker first needs network reachability to the Redis service and valid credentials accepted by AUTH/ACL. In practice this is usually done with redis-cli, a custom client based on hiredis, or stolen app credentials rather than an unauthenticated internet hit. The prerequisite already implies either prior compromise, insider position, or a serious exposure mistake.
Conditions required:
  • TCP reachability to the Redis endpoint
  • A valid Redis password or ACL username/password
  • The target is not fully isolated behind network policy
Where this breaks in practice:
  • Most enterprise Redis is internal-only, not a public web edge service
  • Credential theft is a separate attack stage the CVSS base score does not price in
  • MFA, SSO, or PAM are irrelevant here, but network segmentation often is
Detection/coverage: Network scanners can find open Redis, but they cannot prove exploitability without credentials. Exposure tools catch the port; they do not validate ACL state.
STEP 02

Land on a node where RedisBloom is actually in scope

The vulnerable path only exists when RedisBloom functionality is present. On older deployments that means the standalone bf/RedisBloom module is loaded; on newer Redis 8 lines, probabilistic structures are integrated and the fixed OSS branch level matters. An attacker can check module presence with MODULE LIST or infer capabilities through command behavior.
Conditions required:
  • RedisBloom module is loaded, or the node is a vulnerable Redis 8 build with integrated probabilistic structures
  • The attacker can issue read-only reconnaissance commands
Where this breaks in practice:
  • This is a smaller population than 'all Redis servers'
  • Many fleets run plain cache use cases without RedisBloom at all
  • Module usage is common in specialized search/analytics stacks, not every app tier
Detection/coverage: Authenticated config and module inventory can identify this well. Asset tools that only fingerprint redis-server versions may miss standalone module exposure.
STEP 03

Keep RESTORE permission and deliver a crafted payload

The exploit path depends on sending a malicious serialized value through RESTORE. That usually means a custom client or proof-of-concept logic, though a standard tool like redis-cli can still deliver the command once the payload is prepared. This is the biggest operational choke point because many sane ACLs remove RESTORE or broader dangerous command groups from application users.
Conditions required:
  • The authenticated account can execute RESTORE
  • The attacker can generate a malformed serialized object targeting RedisBloom parsing
Where this breaks in practice:
  • RESTORE is often absent from day-to-day application ACLs
  • Some shops disable or rename dangerous commands entirely
  • GitHub's own CVSS v4 assessment marks attack complexity as High
Detection/coverage: Strong opportunity for command auditing: alert on RESTORE, especially from non-admin app identities. Authenticated vuln scanners usually stop at version checks because exploit validation is unsafe.
STEP 04

Corrupt memory inside redis-server and hope for code execution

If the malformed payload reaches the vulnerable deserializer, RedisBloom can perform invalid memory access inside the Redis process. That can mean a crash, heap corruption, or code execution in the redis-server context depending on allocator behavior, build flags, and exploit quality. Real attackers still have to turn memory corruption into something reliable on your exact target.
Conditions required:
  • A vulnerable code path is hit successfully
  • Target-specific memory layout allows more than a simple crash
Where this breaks in practice:
  • Memory-corruption bugs frequently degrade to denial of service instead of reliable RCE
  • Containers, seccomp, non-root service accounts, and hardening reduce post-exploit payoff
  • There is no strong primary-source evidence of in-the-wild weaponization here
Detection/coverage: Look for RESTORE followed by Redis crashes, abnormal restarts, core dumps, or EDR signals on redis-server. Version scanners cannot distinguish crash-only from exploitable conditions.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo current evidence of active exploitation in retrieved primary sources. Redis disclosed it on 2026-05-05; CISA KEV does not list it in the reviewed catalog page. Sources: Redis advisory, CISA KEV
Proof-of-concept availabilityLimited public code, not strong public weaponization. I found a community GitHub repo focused on scanning/mitigation for the Redis May 2026 CVE set, but not a polished primary-source RCE exploit from the vendor. Sources: community repo, GHSA
EPSS0.00267 (0.267%) from the user-supplied intel. That is low and consistent with a bug that is authenticated, niche, and not currently showing exploitation evidence. FIRST documents EPSS as a probability-of-exploitation signal, not an impact score. Source: FIRST EPSS docs
KEV statusNot KEV-listed. That removes the strongest real-world urgency multiplier. Source: CISA KEV catalog
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H scores the blast radius correctly but underprices the operational friction. GitHub's advisory separately shows a CVSS v4 7.7 with AC:H, which better reflects the exploit chain's practical difficulty. Sources: NVD, GHSA
Affected versionsStandalone RedisBloom: all versions affected per GHSA. NVD describes the vulnerable range as versions before 2.8.20; Redis later published patched builds across old maintained module lines. Redis also states Redis OSS/CE builds were affected until their fixed releases. Sources: GHSA, NVD, Redis advisory
Fixed versionsRedisBloom standalone: 2.4.23, 2.6.28, 2.8.20. Redis OSS/CE: 6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3. Redis Software: 8.0.10-64, 7.22.2-79, 7.8.6-253, 7.4.6-279, 7.2.4-153. Sources: Redis advisory, 2.8.20" target="_blank" rel="noopener">RedisBloom v2.8.20 release, Redis releases
Exposure populationNarrower than generic Redis exposure. The vulnerable path needs RedisBloom functionality plus RESTORE rights, so the reachable population is materially smaller than 'every Redis port on the internet.' I did not find product-specific GreyNoise/Censys/Shodan counts in retrieved primary sources, which is itself a sign this is not currently a headline mass-scan issue.
Disclosure and creditsPublic disclosure landed on 2026-05-05. GitHub credits Joseph Surin and Daniel Firer during the Wiz Zeroday Cloud event; Redis separately attributes the RedisBloom issue to Daniel Firer. Sources: GHSA, Redis advisory
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

The decisive downgrade factor is that exploitation requires authenticated Redis access plus RESTORE permission on a host where RedisBloom is actually present. That makes this a post-initial-access or misconfiguration-amplification bug, not a broad pre-auth internet compromise path.

HIGH Exploit preconditions and affected/fixed version mapping
MEDIUM Real-world exploitation likelihood across enterprise Redis fleets

Why this verdict

  • Down from 8.8 because the attacker already needs a foothold. PR:L on paper means 'low privileges'; in practice it means a valid Redis identity with network reachability, which usually implies prior compromise, insider access, or an exposed service plus stolen creds.
  • Down again because RESTORE is a narrow prerequisite. This is not 'any authenticated command'—the account must retain RESTORE, and many production ACLs strip dangerous commands from app users.
  • Down again because the vulnerable population is smaller than plain Redis. The exploit path needs RedisBloom functionality specifically, and many Redis deployments are just cache tiers without that module or feature set.
  • Held above LOW because the impact is real. If the chain lands, the attacker may get memory corruption and potentially RCE inside redis-server, which can mean data theft, tampering, persistence, or service loss on a central data tier.
  • Held above LOW because patches are available and the bug is easy to reason about operationally. You can identify module presence, Redis branch level, and ACL exposure with straightforward fleet checks.

Why not higher?

There is no strong evidence here of active exploitation, KEV listing, or a broad unauthenticated attack surface. More importantly, every prerequisite compounds downward pressure: internal network reachability, valid Redis auth, RESTORE permission, and RedisBloom presence are not fringe details—they are the attack path.

Why not lower?

This is still an RCE-class memory corruption issue in a high-value infrastructure component. If an attacker already has app-tier access or stolen Redis credentials, the blast radius can be substantial because compromise lands in the Redis process that often sits beside sensitive caches, session stores, or analytics data.

05 · Compensating Control

What to do — in priority order.

  1. Remove RESTORE from non-admin ACLs — This is the cleanest choke point because the exploit path dies without RESTORE. For a MEDIUM noisgate verdict there is no mitigation SLA, so apply this in the next normal change window while you validate who truly needs the command.
  2. Disable or rename RESTORE where legacy ACLs are weak — If you still rely on the default user or broad command groups, use rename-command RESTORE "" or equivalent hardening to kill the path at the server level. Again, no mitigation SLA for MEDIUM—treat it as a sensible hardening change, not a same-day emergency.
  3. Unload RedisBloom where it is not required — If the application does not use probabilistic data structures, removing the module eliminates this CVE's vulnerable code path entirely. Schedule it in the next maintenance window; for this severity there is no mitigation SLA.
  4. Constrain Redis reachability to trusted app tiers — This does not fix the bug, but it shrinks the number of identities and systems that can even attempt the chain. Fold the ACL/network review into your routine segmentation work; for MEDIUM there is no mitigation SLA.
What doesn't work
  • AUTH by itself does not help much because the vulnerability already assumes an authenticated attacker.
  • A web application firewall is irrelevant because this is a Redis protocol issue, not an HTTP attack path.
  • Internet perimeter blocking alone is incomplete if the real threat is lateral movement from a compromised internal app host.
  • Generic version-only scanning can miss standalone RedisBloom module state and may overstate or understate actual exposure.
06 · Verification

Crowdsourced verification payload.

Run this on the target Redis host or from an auditor workstation that has redis-cli and network access to the instance. Invoke it as ./check_cve_2026_25589.sh -h 10.0.0.25 -p 6379 -u auditor -a 'secret'; read-only creds are enough for version/module checks, but ACL inspection works best with admin-level visibility.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_25589.sh
# Determine likely exposure to CVE-2026-25589 (RedisBloom RESTORE invalid memory access)
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

HOST="127.0.0.1"
PORT="6379"
USER=""
PASS=""
TIMEOUT_BIN="timeout"

usage() {
  echo "Usage: $0 [-h host] [-p port] [-u user] [-a password]"
}

while getopts ":h:p:u:a:" opt; do
  case "$opt" in
    h) HOST="$OPTARG" ;;
    p) PORT="$OPTARG" ;;
    u) USER="$OPTARG" ;;
    a) PASS="$OPTARG" ;;
    *) usage; exit 2 ;;
  esac
done

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

redis_cmd() {
  local args=( -h "$HOST" -p "$PORT" --raw )
  if [ -n "$USER" ]; then
    args+=( --user "$USER" )
  fi
  if [ -n "$PASS" ]; then
    args+=( -a "$PASS" )
  fi
  if command -v "$TIMEOUT_BIN" >/dev/null 2>&1; then
    "$TIMEOUT_BIN" 5 redis-cli "${args[@]}" "$@" 2>/dev/null
  else
    redis-cli "${args[@]}" "$@" 2>/dev/null
  fi
}

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

version_lt() {
  ! version_ge "$1" "$2"
}

normalize_modver() {
  # convert Redis module integer version (e.g. 20819) to semver (2.8.19)
  local n="$1"
  if [[ ! "$n" =~ ^[0-9]+$ ]]; then
    echo ""
    return
  fi
  local major minor patch
  if [ ${#n} -ge 5 ]; then
    major=${n:0:1}
    minor=${n:1:2}
    patch=${n:3}
  elif [ ${#n} -eq 4 ]; then
    major=${n:0:1}
    minor=${n:1:1}
    patch=${n:2}
  else
    echo ""
    return
  fi
  minor=$((10#$minor))
  patch=$((10#$patch))
  echo "${major}.${minor}.${patch}"
}

INFO_OUT="$(redis_cmd INFO server)"
if [ -z "$INFO_OUT" ]; then
  echo "UNKNOWN - unable to query Redis INFO"
  exit 2
fi

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

MODULE_OUT="$(redis_cmd MODULE LIST)"
WHOAMI="$(redis_cmd ACL WHOAMI)"
ACL_OUT=""
if [ -n "$WHOAMI" ] && [ "$WHOAMI" != "NOPERM" ] && [ "$WHOAMI" != "ERR unknown command 'ACL'" ]; then
  ACL_OUT="$(redis_cmd ACL GETUSER "$WHOAMI")"
fi

RESTORE_BLOCKED="unknown"
if printf '%s' "$ACL_OUT" | grep -Eqi '(^|[[:space:]])-restore([[:space:]]|$)|(^|[[:space:]])-@dangerous([[:space:]]|$)'; then
  RESTORE_BLOCKED="yes"
elif [ -n "$ACL_OUT" ]; then
  RESTORE_BLOCKED="no"
fi

BF_MODVER_RAW="$(printf '%s
' "$MODULE_OUT" | awk '
  BEGIN{found=0; name=""; ver=""}
  /^name$/ {getline; name=$0}
  /^ver$/ {getline; ver=$0; if (name=="bf" || name=="redisbloom") {print ver; exit}}
')"
BF_MODVER="$(normalize_modver "$BF_MODVER_RAW")"

# Decision tree
# 1) Standalone RedisBloom module loaded -> evaluate module version if possible
# 2) No module loaded and Redis < 8 -> this specific CVE path is not present
# 3) Redis >= 8 may include integrated probabilistic structures -> evaluate OSS branch fixes conservatively

if [ -n "$BF_MODVER_RAW" ]; then
  if [ -z "$BF_MODVER" ]; then
    echo "UNKNOWN - RedisBloom module present but module version could not be normalized (raw=$BF_MODVER_RAW, redis=$REDIS_VER, restore_blocked=$RESTORE_BLOCKED)"
    exit 2
  fi

  VULN="unknown"
  case "$BF_MODVER" in
    2.4.*)
      if version_lt "$BF_MODVER" "2.4.23"; then VULN="yes"; else VULN="no"; fi ;;
    2.6.*)
      if version_lt "$BF_MODVER" "2.6.28"; then VULN="yes"; else VULN="no"; fi ;;
    2.8.*)
      if version_lt "$BF_MODVER" "2.8.20"; then VULN="yes"; else VULN="no"; fi ;;
    *)
      # GHSA says all versions affected; if we see an unrecognized line, stay conservative
      VULN="yes" ;;
  esac

  if [ "$VULN" = "yes" ]; then
    echo "VULNERABLE - RedisBloom module $BF_MODVER on Redis $REDIS_VER (restore_blocked=$RESTORE_BLOCKED)"
    exit 1
  else
    echo "PATCHED - RedisBloom module $BF_MODVER on Redis $REDIS_VER (restore_blocked=$RESTORE_BLOCKED)"
    exit 0
  fi
fi

REDIS_MAJOR="${REDIS_VER%%.*}"
if [[ ! "$REDIS_MAJOR" =~ ^[0-9]+$ ]]; then
  echo "UNKNOWN - could not parse Redis major version from $REDIS_VER"
  exit 2
fi

if [ "$REDIS_MAJOR" -lt 8 ]; then
  echo "PATCHED - no RedisBloom module loaded and Redis version is $REDIS_VER (<8 integrated path not present)"
  exit 0
fi

# Redis 8+ integrated probabilistic structures: compare against published OSS fixed branches.
# Conservative interpretation:
# - 8.2.x fixed at 8.2.6
# - 8.4.x fixed at 8.4.3
# - 8.6.x fixed at 8.6.3
# - 8.8+ assumed patched based on later maintained branch publication
# - 8.0.x/8.1.x/8.3.x/8.5.x treated as vulnerable/unknown-adjacent; keep conservative
case "$REDIS_VER" in
  8.2.*)
    if version_lt "$REDIS_VER" "8.2.6"; then
      echo "VULNERABLE - Redis $REDIS_VER integrated probabilistic path below 8.2.6 (restore_blocked=$RESTORE_BLOCKED)"
      exit 1
    else
      echo "PATCHED - Redis $REDIS_VER >= 8.2.6 (restore_blocked=$RESTORE_BLOCKED)"
      exit 0
    fi ;;
  8.4.*)
    if version_lt "$REDIS_VER" "8.4.3"; then
      echo "VULNERABLE - Redis $REDIS_VER integrated probabilistic path below 8.4.3 (restore_blocked=$RESTORE_BLOCKED)"
      exit 1
    else
      echo "PATCHED - Redis $REDIS_VER >= 8.4.3 (restore_blocked=$RESTORE_BLOCKED)"
      exit 0
    fi ;;
  8.6.*)
    if version_lt "$REDIS_VER" "8.6.3"; then
      echo "VULNERABLE - Redis $REDIS_VER integrated probabilistic path below 8.6.3 (restore_blocked=$RESTORE_BLOCKED)"
      exit 1
    else
      echo "PATCHED - Redis $REDIS_VER >= 8.6.3 (restore_blocked=$RESTORE_BLOCKED)"
      exit 0
    fi ;;
  8.[89].*|9.*)
    echo "PATCHED - Redis $REDIS_VER is on a later branch than the published OSS fixes reviewed (restore_blocked=$RESTORE_BLOCKED)"
    exit 0 ;;
  8.*)
    echo "VULNERABLE - Redis $REDIS_VER is an early/unlisted 8.x branch; compare against vendor-fixed builds manually (restore_blocked=$RESTORE_BLOCKED)"
    exit 1 ;;
  *)
    echo "UNKNOWN - unexpected Redis version format: $REDIS_VER"
    exit 2 ;;
esac
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, split the problem into three buckets: Redis nodes with no RedisBloom path, standalone RedisBloom nodes, and Redis 8 integrated nodes. This is MEDIUM, so there is no noisgate mitigation SLA — go straight to the 365-day remediation window; use that time to inventory MODULE LIST, confirm whether app identities still have RESTORE, and fold ACL cleanup into routine hardening. Then finish the real fix inside the noisgate remediation SLA by upgrading standalone RedisBloom to 2.4.23/2.6.28/2.8.20 or Redis OSS/CE to 6.2.22/7.2.14/7.4.9/8.2.6/8.4.3/8.6.3 within ≤365 days.

Sources

  1. Redis security advisory for May 5, 2026 Redis CVEs
  2. GitHub Security Advisory GHSA-7862-34pw-44wv
  3. NVD record for CVE-2026-25589
  4. RedisBloom standalone patch release v2.8.20
  5. Redis releases page showing 8.2.6 security fixes
  6. Ubuntu tracker entry for CVE-2026-25589
  7. CISA Known Exploited Vulnerabilities Catalog
  8. FIRST EPSS data and statistics documentation
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.