Valkey 7.2: What's New, Release History & Support Lifecycle

What Is New in Valkey 7.2

Valkey 7.2 is the first stable release line under the Valkey brand, forked from Redis 7.2 after the license change. The series spans patch releases 7.2.5 through 7.2.12 and is focused on branding alignment, security hardening, cluster and TLS stability, and a steady stream of targeted bug fixes. If you are running any Redis 7.2-compatible workload and need an open-source drop-in, this is the branch to evaluate.

What Is New in Valkey 7.2 -- Summary

What changed in Valkey 7.2 branding and configuration defaults?

Valkey 7.2 replaces all redis.io references in template configuration files with valkey.io, making the project self-consistent under its new identity. In practice this affects the comments and default URL values inside valkey.conf and related templates -- not runtime behavior. Teams migrating from Redis 7.2 will find the wire protocol, RDB format, and command set fully compatible; only the documentation pointers and branding strings change.

This matters if you use automated config auditing tools that scan for redis.io URLs: those scanners will now encounter valkey.io instead, and any allowlists or linting rules should be updated accordingly.

# Example: updated default in valkey.conf template
# Documentation: https://valkey.io/commands/

What critical security vulnerabilities were patched in Valkey 7.2?

The 7.2.x series received eight CVE-level security fixes across its patch history, several of which are rated high-severity. Any deployment running 7.2.x in production should upgrade to 7.2.12 at minimum.

• CVE-2025-27151 (7.2.10) -- valkey-check-aof did not validate the length of AOF file paths. A path exceeding PATH_MAX could cause undefined behavior. Fix: reject paths longer than PATH_MAX at startup.
• CVE-2025-32023 (7.2.10) -- An out-of-bounds write was possible during HyperLogLog operations. Watch out for this one if you use PFADD/PFCOUNT heavily or expose the port to untrusted clients.
• CVE-2025-48367 (7.2.10) -- Transient errors during accept() were not retried, which could be leveraged to interrupt connection acceptance. The fix retries on recoverable errno values.
• CVE-2025-49844 / CVE-2025-46817 / CVE-2025-46818 / CVE-2025-46819 (7.2.11) -- A cluster of four Lua vulnerabilities: remote code execution, integer overflow leading to potential RCE, script execution in the context of another user, and an out-of-bounds read. These affect any instance where untrusted users can run EVAL or EVALSHA. Upgrade urgency is SECURITY for 7.2.11 specifically because of this group.
• CVE-2026-21863 (7.2.12) -- A malformed Valkey Cluster bus message could trigger a remote denial of service. Any cluster deployment is exposed until upgraded.
• CVE-2025-67733 (7.2.12) -- RESP protocol injection was possible via Lua error_reply. An attacker who can run Lua scripts could craft replies that confused the client parser.

Most teams running managed Valkey on a cloud provider will have these applied automatically, but self-managed clusters need a manual rolling upgrade. The security fixes are backported cleanly and carry no behavioral regressions in validated scenarios.

Which cluster and TLS stability bugs were fixed in Valkey 7.2?

Cluster and TLS bugs dominated the 7.2.x patch queue, making this an important maintenance branch for anyone running Valkey in cluster mode or with TLS termination.

• TLS outbound crash (7.2.10) -- When SSL_new() returned NULL on a new outbound connection, the engine crashed instead of handling the error gracefully. This surfaced under memory pressure or misconfigured TLS contexts.
• Cluster bus packet misclassification (7.2.10) -- Large cluster bus extensions could cause a valid packet to be marked invalid, silently dropping cluster gossip messages. In practice this caused nodes to appear unreachable even when they were not.
• Stale CLUSTER SLOTS / CLUSTER NODES after port change (7.2.10) -- Dynamic port or tls-port reconfiguration did not invalidate the cached cluster topology response. Clients using CLUSTER SLOTS for automatic routing would be redirected to the wrong endpoint until the node was restarted.
• Replica failover stall on outdated config epoch (7.2.10) -- A replica with a stale config epoch could not complete failover, leaving the shard without a writable primary. The fix ensures the epoch is refreshed before proceeding.
• Potential infinite loop in clusterNodeGetMaster (7.2.12) -- A specific cluster state (replica pointing back to itself via a cycle in the node graph) could hang the server thread. This was introduced by a prior optimization and is now guarded with a cycle-detection check.
• MODULE UNLOAD crash with ACL references (7.2.12) -- Unloading a module while an ACL rule referenced one of its commands or subcommands caused a crash. This is relevant for any deployment using Valkey modules behind fine-grained ACL policies.

If you are using Valkey Cluster with dynamic port reconfiguration or module-backed ACLs, the jump from 7.2.5 to 7.2.12 is particularly impactful and worth scheduling as soon as possible.

What server-side bug fixes affect everyday operations in Valkey 7.2?

Beyond security and cluster fixes, the 7.2.x series also addressed several bugs that affect daily workloads -- especially those using Lua scripting, CLIENT PAUSE, streams, and memory tracking.

• CLIENT UNBLOCK unpausing paused clients (7.2.10) -- Issuing CLIENT UNBLOCK on a client that was paused via CLIENT PAUSE incorrectly cleared the pause state. This could allow commands to execute during a maintenance window where writes were expected to be blocked.
• Lua empty error table crash (7.2.11) -- A Lua script returning an empty error table via redis.error_reply({}) caused the server to crash with an assertion. This is a relatively uncommon pattern but does appear in some error-handling wrappers.
• RANDOMKEY infinite loop during CLIENT PAUSE (7.2.9) -- When all keyspace slots were paused, RANDOMKEY could spin indefinitely. This blocked the event loop and caused timeouts for all connected clients.
• XINFO GROUPS incorrect lag (7.2.9) -- Stream consumer group lag was miscalculated under certain conditions, producing misleading values in monitoring dashboards built on XINFO GROUPS.
• Client tracking memory overhead miscalculation (7.2.11) -- The reported used_memory_overhead for client tracking was underreported, making memory capacity planning based on INFO MEMORY unreliable on instances with many tracked clients.
• Defrag crash with FLUSHDB ASYNC in cluster mode (7.2.9) -- Running FLUSHDB ASYNC while active defragmentation was in progress on a cluster node could cause a crash. Most teams hit this during slot migration prep or cache warm-up cycles.
• LTRIM unnecessary keyspace notification (7.2.12) -- LTRIM called signalModifiedKey even when no elements were actually removed, generating spurious keyspace events and waking up unnecessary client watches.
• Stricter CRLF parsing (7.2.5) -- The query buffer parser now strictly validates CRLF sequences. This closes a subtle protocol ambiguity that could theoretically be exploited to inject malformed commands.

Should you upgrade from Redis 7.2 to Valkey 7.2, and what does migration look like?

Valkey 7.2 is binary-compatible with Redis 7.2 at the wire-protocol level: the same RESP2/RESP3 protocol, identical command set, and compatible RDB format. For most teams the migration is a drop-in replacement -- swap the binary, update config file URL comments, and restart.

In practice, the key things to audit before migrating are listed below.

• Config file templates -- The bundled valkey.conf replaces redis.io URLs with valkey.io. If you diff your live config against the packaged template as part of configuration management, update your baseline.
• Monitoring dashboards -- Some INFO field names and log prefixes now say "Valkey" where they previously said "Redis". Regex-based log parsers and Prometheus label extractors may need updating.
• Module compatibility -- Modules compiled against the Redis module API are generally compatible, but any module that references internal symbols by name should be tested. Modules using ACL command references should be tested with the 7.2.12 MODULE UNLOAD fix in mind.
• Client libraries -- All major Redis client libraries (Jedis, StackExchange.Redis, hiredis, go-redis, ioredis) work with Valkey 7.2 without modification. Some have begun adding native Valkey detection but this does not affect compatibility.

# Minimal upgrade procedure for a standalone instance
# 1. Install Valkey 7.2.12 alongside existing Redis 7.2
# 2. Copy and adjust redis.conf -> valkey.conf (update bind, requirepass, etc.)
# 3. Perform a CONFIG REWRITE on Redis to capture current runtime config
# 4. Test with PING / INFO server -- verify Valkey version string
# 5. Execute rolling restart (replica first, then primary with CLUSTER FAILOVER)

Watch out for any application code that parses the SERVER section of INFO and specifically matches on the string "redis_version". Valkey returns "valkey_version" in that field, so client version detection logic must be updated.