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.
4 steps from start to impact.
Reach Redis and authenticate with a usable account
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.- TCP reachability to the Redis endpoint
- A valid Redis password or ACL username/password
- The target is not fully isolated behind network policy
- 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
Land on a node where RedisBloom is actually in scope
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.- 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
- 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
redis-server versions may miss standalone module exposure.Keep RESTORE permission and deliver a crafted payload
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.- The authenticated account can execute
RESTORE - The attacker can generate a malformed serialized object targeting RedisBloom parsing
RESTOREis 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
RESTORE, especially from non-admin app identities. Authenticated vuln scanners usually stop at version checks because exploit validation is unsafe.Corrupt memory inside redis-server and hope for code execution
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.- A vulnerable code path is hit successfully
- Target-specific memory layout allows more than a simple crash
- 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
RESTORE followed by Redis crashes, abnormal restarts, core dumps, or EDR signals on redis-server. Version scanners cannot distinguish crash-only from exploitable conditions.The supporting signals.
| In-the-wild status | No 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 availability | Limited 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 |
| EPSS | 0.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 status | Not KEV-listed. That removes the strongest real-world urgency multiplier. Source: CISA KEV catalog |
| CVSS vector reality check | CVSS: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 versions | Standalone 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 versions | RedisBloom 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 population | Narrower 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 credits | Public 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 |
noisgate verdict.
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.
Why this verdict
- Down from 8.8 because the attacker already needs a foothold.
PR:Lon 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
RESTOREis a narrow prerequisite. This is not 'any authenticated command'—the account must retainRESTORE, 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.
What to do — in priority order.
- Remove
RESTOREfrom non-admin ACLs — This is the cleanest choke point because the exploit path dies withoutRESTORE. 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. - Disable or rename
RESTOREwhere legacy ACLs are weak — If you still rely on the default user or broad command groups, userename-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. - 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.
- 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.
AUTHby 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.
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.
#!/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
If you remember one thing.
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
- Redis security advisory for May 5, 2026 Redis CVEs
- GitHub Security Advisory GHSA-7862-34pw-44wv
- NVD record for CVE-2026-25589
- RedisBloom standalone patch release v2.8.20
- Redis releases page showing 8.2.6 security fixes
- Ubuntu tracker entry for CVE-2026-25589
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS data and statistics documentation
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.