Which Valkey Versions Are Still Patched? Support Windows and the Minimum Safe Patch

Valkey patches five release lines at once: 9.1, 9.0, 8.1, 8.0, and 7.2. On 26 and 27 October 2026 every one of them shipped a release marked "Upgrade urgency SECURITY" for a cluster Pub/Sub heap overflow, GHSA-f4q9-j22m-xqq9. That advisory has no CVE ID, so a scanner that matches CVEs does not flag it. The support dates differ by branch in a way that is easy to misread. Valkey 9.0 and 8.0 get no extended security window: their support simply stops in 2028 and 2027. And since September 2026, some security-relevant fixes ship as ordinary bug fixes with no advisory at all. This post gives the support window for each branch, the minimum patch to run on each as of November 2026, the advisories each floor closes, and how to roll a patch out and keep up with the next one.

Scope and review date: November 2026. This post covers self-managed Valkey 7.2, 8.0, 8.1, 9.0, and 9.1, plus a note on the 9.2 release candidates. Dates, versions, and advisories were checked against valkey.io, the Valkey GitHub releases and security advisories, and Docker Hub on 10 November 2026. The commands were checked against the documentation and source, not run in a lab, so rehearse them on staging.

Which Valkey versions are supported, and until when?

The Valkey releases and versioning page sets two windows. Maintenance support, meaning "patch releases for bug fixes and all security fixes", lasts 3 years from a minor version's first release. Extended security support lasts 5 years, but only for the latest minor version of each major. The page adds that the project "will only patch security issues we believe to be possible to exploit", at the discretion of the Technical Steering Committee (TSC).

That second rule is why the table has two short lines. 8.1 is the last 8.x minor, so 8.0 gets no extended period. 9.0 is not the last 9.x minor, so it stops at its maintenance date.

Support dates come from the releases page. The patch floor is the newest release on each branch, listed on the Valkey download page and in the GitHub release notes.

Which advisories does each patch floor close?

Every advisory published in 2026 is fixed at or below the floor on each affected branch. The matrix lists the first fixed release per branch, from the Valkey security advisories and the GitHub release notes. A dash means the advisory does not list that branch as affected.

Three 2026 advisories had no CVE ID on 10 November 2026: GHSA-jcj7-v34w-v9vv, GHSA-fq2f-crmw-q97r, and GHSA-f4q9-j22m-xqq9. The May CVEs have no Valkey repository advisory and appear only in release notes, and 7.2.14 lists one more zipmap RESTORE fix under CVE-2026-25243. Track by GHSA ID and release version, not by CVE alone. One small discrepancy: the CVE-2025-67733 advisory lists 9.0.2 as patched, while the fix appears in the 9.0.3 notes. The 9.0 floor covers both.

# List Valkey advisories with their CVE (if any) and patched versions
gh api "repos/valkey-io/valkey/security-advisories?per_page=100" \
  --jq '.[] | [.ghsa_id, (.cve_id // "no CVE"), .severity,
              ([.vulnerabilities[].patched_versions] | join(" "))] | @tsv'

Interpretation: each line pairs a GHSA ID with its CVE, or "no CVE", and the patched versions per branch. Feed the GHSA IDs, not just CVEs, into your vulnerability tracker. On a release older than 2026, the 2025 Lua advisories (CVE-2025-49844 and three related CVEs, fixed in 8.1.4, 8.0.6, and 7.2.11) also apply; the floor fixes those as well.

If you cannot patch this week

The GHSA-f4q9-j22m-xqq9 advisory notes that building a message over 4 GiB needs a script, because the default proto-max-bulk-len of 512 MB blocks large client arguments. Its mitigation is to deny scripting commands to users who do not need them and to keep that limit at its default.

valkey-cli CONFIG GET proto-max-bulk-len
valkey-cli ACL SETUSER reporting -@scripting
valkey-cli ACL GETUSER reporting

Interpretation: 536870912 is the 512 MB default. -@scripting removes EVAL, FCALL, FUNCTION, and the other scripting commands from that user. This narrows exposure for one advisory; it is not a substitute for the floor.

Which security fixes shipped without an advisory?

In a 17 September 2026 post, the maintainers changed what gets an advisory: Valkey "stopped issuing advisories for availability-only bugs that require an authenticated attacker", and fixes them as ordinary bugs. A pre-authentication crash, an out-of-bounds read, or "any action beyond granted permissions" still gets one. The same post counts seven advisories in the first eight months of 2026 and "almost three dozen security-adjacent fixes".

In practice several permission fixes appear only in the "Bug Fixes" list of a release:

Note the 7.2 dates. The GEORADIUS and cluster bus fixes reached 8.x and 9.x on 31 August and 1 September 2026, but 7.2 only in 7.2.15, eight weeks later. The same thing can happen to any branch in its security-only period, which receives security fixes but not ordinary bug fixes. Our reading of the September policy is that authenticated crash bugs may then not reach it at all.

# Every fix between your running patch and the floor, ACL items first
gh release view 9.0.7 --repo valkey-io/valkey | grep -iE "acl|permission|tls|inject"
gh release view 9.0.6 --repo valkey-io/valkey | grep -iE "acl|permission|tls|inject"

Interpretation: run it for every release between your current patch and the floor, because release notes list only the changes since the previous patch. Each hit is a permission or input-validation fix that a CVE feed will not show.

What else changes when you apply a Valkey security patch?

The releases page says patch versions carry backward-compatible bug fixes and that upgrading between them "should be safe". The fixes still change behavior that applications and scripts can see. These are the ones most likely to surface in testing:

• Strict CRLF parsing (#2872). Requests without proper line endings now get a protocol error instead of being misparsed. In 9.0.5, 8.1.8, 8.0.10, and 7.2.14; in 9.1 since 9.1.0-rc1. Hand-written health checks are the usual casualty.
• COMMAND INFO in RESP3 (#3939). The subcommands field is now an array, not a set. In 9.1.1, 9.0.5, 8.1.9, 8.0.10, and 7.2.14.
• lua-enable-insecure-api (#3548). A yes set in the config file now takes effect at startup; before, it was ignored. In 8.1.9, 8.0.10, and 7.2.14. Check the file before you patch.
• AOF replay and dump validation (#3984, #3721). Replaying the AOF no longer applies ACL checks, and sanitize-dump-payload became a no-op with deep validation always on. In 9.1.2, 9.0.6, 8.1.10, 8.0.11, and 7.2.15.
• Hash field commands (#4576, #4300). HGETEX needs write permission, and HPERSIST, HTTL, HPTTL, HEXPIRETIME, and HPEXPIRETIME return a syntax error without FIELDS. In 9.1.2 and 9.0.6.
• The October wave. LSET with an out-of-range index returns an error instead of changing the wrong element (all five branches). A negative sorted set LIMIT offset returns an empty result (all but 7.2). The cluster startup lock moved to a separate nodes.conf.lock file (all five), and PUBLISH over the cluster bus size limit now returns an error.

# Find code paths that hit the commands whose replies changed
grep -rnE "HGETEX|HPERSIST|HTTL|HPTTL|HEXPIRETIME|LSET|COMMAND INFO" ./src
# Check whether the config file asks for the insecure Lua API
grep -n "lua-enable-insecure-api" /etc/valkey/valkey.conf

Interpretation: any hit is a test to run on staging against the target patch. If the second command prints lua-enable-insecure-api yes, decide whether you still want it before the patch makes it real. Backup and file-sync tools that copy the data directory should expect nodes.conf.lock on cluster nodes.

How do you check which Valkey version is actually running?

Ask the server. Package versions, image tags, and the Redis compatibility field all mislead. Every Valkey release reports redis_version:7.2.4 in INFO server, hard-coded as a compatibility value that "should never exceed 7.2.x" in version.h. The real version is in valkey_version.

With extended-redis-compatibility yes, the HELLO reply also claims to be Redis 7.2.4, per networking.c at 9.1.3. INFO server keeps both fields either way. Off the server, the binary reports its own version:

valkey-server --version
docker run --rm valkey/valkey:8 valkey-server --version

Interpretation: the output starts with Valkey server v= and the version. On 10 November 2026 the floating valkey/valkey:8 tag had the same digest as 8.1.11, and latest matched 9.1.3. A team that reads :8 as "the 8.0 line" is running 8.1. Pin the full patch tag. Bundles number separately: the valkey-bundle 9.1.4 Dockerfile builds on Valkey 9.1.3.

The revoked 8.0.8 release

Valkey 8.0.8 appeared on 6 May 2026 with the other May security releases. Its release, now titled "8.0.8 (revoked)", says: "The 8.0.8 tag was placed on a commit that is not part of the 8.0 release branch. Users should upgrade to 8.0.9 instead." 8.0.9 followed the same day with the three May CVE fixes. GitHub's compare view shows the 8.0.8 tag 1,292 commits ahead of 8.0.7 and diverged from it. The tagged version.h carries the development placeholder version, so a server built from it reports:

valkey-cli INFO server | grep -E "valkey_version|valkey_release_stage"
# valkey_version:255.255.255  means a development build, such as the 8.0.8 tag

Interpretation: 255.255.255 is the version string of Valkey's unstable branch. Any node reporting it is not running an 8.0 release. Docker Hub has no 8.0.8 tag, so the risk is in source builds and internal mirrors. Rebuild those nodes from 8.0.12.

Should you patch in place or move to a newer branch?

Do both, in that order. A patch on the same branch is the smallest change: the releases page says it should be safe to run "a primary-replica pair or a Valkey cluster with servers running on different patch versions". Moving branch is a minor or major upgrade, and the same page says it is "not recommended to run a Valkey cluster with servers running on different minor versions", so that rollout needs a shorter, planned window.

Some branch-specific notes for step 3. From 9.0, go straight to 9.1.3 or later: earlier 9.1 releases had a listpack incompatibility that broke RDB loads and replication with 9.0 for some entry sizes (#4819). The Valkey 9.1 upgrade guide covers that path and its rollback limits. From 7.2, a move to 8.1 keeps the same RDB format: rdb.h describes RDB 11 as "used by Valkey 7.x and 8.x", while 9.x writes version 80.

# How long does each branch you run have left? (GNU date)
for d in 2027-09-15 2028-10-21; do
  echo "$d: $(( ( $(date -d "$d" +%s) - $(date +%s) ) / 86400 )) days"
done

Interpretation: the two dates are the support ends for 8.0 and 9.0. If the count is shorter than your usual lead time for a tested upgrade, step 3 belongs in this quarter's plan.

How do you roll a Valkey patch through replicas and the primary?

The releases page says to "always upgrade replicas before upgrading primaries". For a patch release, each node is a stop, binary swap, and start. The only write interruption is the controlled failover.

On managed services such as Amazon ElastiCache or Google Cloud Memorystore, the provider builds and schedules engine versions. Check which Valkey patch your engine version corresponds to in the provider's own release notes rather than assuming the open source floor applies.

How do you track new Valkey releases and advisories?

Valkey ships most security fixes to every supported branch within a day, so one feed covers all of them. Three sources are enough:

• GitHub watch. On the valkey-io/valkey repository, choose Watch, then Custom, then Releases. GitHub's notification settings documentation describes the custom options.
• The release feed. Release notes carry an "Upgrade urgency" line: LOW, MODERATE, HIGH, or SECURITY. Alert on SECURITY and HIGH.
• The advisories API. Poll it on a schedule and diff against the last run, so advisories without a CVE are not missed.

# Newest releases, then the urgency line of one release
curl -s https://github.com/valkey-io/valkey/releases.atom | grep -o "<title>[^<]*" | head -8
gh release list --repo valkey-io/valkey --limit 10
gh release view 9.1.3 --repo valkey-io/valkey | grep "Upgrade urgency"

Interpretation: the Atom feed and gh release list show the newest tags, including release candidates such as 9.2.0-rc2 from 4 November 2026. The download page states that release candidates "are not supported for production use", so leave them out of the floor. The urgency line tells you how fast to act.

Frequently asked questions

Key takeaways

Keep your Valkey fleet patched with JusDB

JusDB's Valkey support team can review the versions running across your nodes against the current patch floor, check the release notes between each version and its target for behavior changes, and plan or run the rolling upgrades, including the 8.0 and 9.0 branch moves.

Bring your node list, current versions, topology (standalone, Sentinel, or cluster), and maintenance windows. Your team approves every production change.

Related reading

• Valkey 9.1 for operators: what changed and how to upgrade
• Redis 8 vs Valkey 8 in production
• Valkey performance tuning: memory, persistence, and cluster config
• Valkey documentation: Releases and versioning schema