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

What Is New in Valkey 9.1

What security vulnerabilities were patched in Valkey 9.1?

Valkey 9.1 ships three CVE-level security fixes that production operators should treat as mandatory, even under the LOW upgrade urgency rating.

• CVE-2026-23479 -- Use-After-Free in unblock client flow. A use-after-free condition could be triggered in the client unblocking path. Any code path that blocks a client (BLPOP, BRPOP, WAIT, module-blocked clients) and then unblocks it under specific timing was potentially exploitable. Clusters serving high-throughput blocking workloads should prioritize this patch.
• CVE-2026-25243 -- Invalid Memory Access in RESTORE command. Crafted input to RESTORE could cause an invalid memory read. This matters if you accept RESTORE calls from untrusted clients or run migration tooling that pipes RDB data through RESTORE. Watch out for this in multi-tenant deployments where keyspace isolation relies on ACLs alone.
• CVE-2026-23631 -- Use-after-free during full sync with yielding Lua/function execution. A race between a full replication sync and a yielding Lua script or FUNCTION could free memory still in use. Most teams running Lua-heavy workloads alongside active replica sync (for example, during failovers) are exposed to this one.

All three are memory-safety issues. Even if direct exploitation paths are narrow in your environment, memory corruption bugs can surface as silent data corruption before they appear as crashes. Upgrade promptly.

How does Valkey 9.1 improve cluster observability and network monitoring?

Valkey 9.1 introduces a new cluster bus network traffic metric reported in bytes, giving operators a direct measurement of intra-cluster gossip overhead for the first time.

In a large cluster (hundreds of nodes, many slots, frequent topology changes), the cluster bus can quietly become a non-trivial consumer of network bandwidth. Previously, teams had to approximate this by correlating OS-level interface counters with instance counts -- a fragile approach that broke under NAT or when multiple instances shared a host. This metric surfaces the byte count directly from within Valkey, making it straightforward to alert on gossip storms or size network provisioning for new clusters.

# Check cluster bus traffic via INFO
127.0.0.1:6379> INFO cluster
# cluster
cluster_enabled:1
cluster_bus_io_bytes_received:148203
cluster_bus_io_bytes_sent:221890
...

Watch out for sudden spikes in this counter after topology changes or during slot migration -- those are the scenarios most likely to reveal unexpected gossip amplification.

Does Valkey 9.1 reduce latency spikes during dictionary rehashing?

Yes -- Valkey 9.1 addresses one of the subtler sources of latency variance in memory-heavy deployments by introducing incremental page release during rehashing.

When Valkey resizes a dictionary (triggered by load factor thresholds during heavy write bursts), the old hash table backing memory is freed. On Linux with transparent huge pages or jemalloc page retention, bulk frees have historically caused brief but measurable latency spikes as the allocator reconciles its internal bookkeeping and the kernel reclaims pages. This change releases pages incrementally across rehashing steps rather than all at once, spreading that cost over time.

In practice, this improvement is most impactful for instances holding large keyspaces (tens of millions of keys) that experience rapid key churn -- think session stores, rate limiters, or queue-like patterns where keys are created and expired at high rates. Most teams running smaller keyspaces with stable cardinality will see negligible difference.

What bugs were fixed in Valkey 9.1 that could affect production stability?

The 9.1 release includes five targeted bug fixes, two of which carry real production risk.

• GEOSEARCH BYPOLYGON memory leak on invalid COUNT. Passing an invalid COUNT argument to GEOSEARCH with a BYPOLYGON filter leaked memory on each call. If your application validates input upstream this is low risk, but any API endpoint passing user-controlled COUNT values directly to GEOSEARCH was accumulating heap pressure silently.
• NULL pointer crash in streamTrim listpack delta calculation. A NULL pointer dereference in the stream trimming code path could crash the server under specific listpack state conditions. Stream-heavy workloads using XADD with MAXLEN or MINID trimming should treat this as a priority fix.
• syncRead EOF error propagation fix. EOF conditions during synchronous I/O were not correctly setting errno, which could mask connection errors in error-handling paths and lead to incorrect retry behavior or stale connection states.
• RDMA benchmark crash on client disconnect. A crash in the RDMA code path when benchmark clients disconnected abruptly. This only affects setups running RDMA transport.
• valkey-benchmark memory leak. A memory leak in the valkey-benchmark tool itself. No production server impact, but worth noting for teams running sustained benchmark suites in CI pipelines.