Valkey and Redis cluster Pub/Sub overflow: who is affected and how to patch

On October 26, 2026, the Valkey project shipped security releases across six release lines, and Redis shipped a matching fix the same day. The bug is a heap buffer overflow in how a node in cluster mode passes a published message to the rest of the cluster. If your app uses Valkey or Redis for caching, queues, sessions or real-time features, here's how to tell whether you're affected and how to patch without taking your app down.

What happened

The Valkey advisory, GHSA-f4q9-j22m-xqq9, is rated High with a CVSS score of 8.8. It was reported by Nenad Stojanovski working with Trend Micro's Zero Day Initiative.

In plain terms: when a cluster node passes a PUBLISH or SPUBLISH message on to the other nodes, it works out the size of the message it needs to send. That size was squeezed into a 32-bit number. If the channel name and message together are larger than about 4 GiB, the number wraps around, the server sets aside a buffer that is far too small, and then copies the whole message into it. The extra bytes spill past the end of the buffer.

The advisory says this reliably crashes the server. Because the attacker chooses the overflowing bytes, it may also be possible to turn it into remote code execution, running as whatever system user the server runs as.

The fix checks the full message size before any conversion. Oversized PUBLISH and SPUBLISH calls now return an error, and the message is not published or passed on.

Are you affected?

Work through these three questions.

1. Are you running in cluster mode?

This is the big one. The advisory states that servers without cluster mode enabled are not affected. Many small apps run a single Valkey or Redis instance, sometimes with a replica, and never turn on cluster mode. Check your config for cluster-enabled yes, or run INFO cluster and look at cluster_enabled.

2. Which version are you on?

Valkey versions up to and including these are affected:

| Line | Affected up to | Fixed in | |---|---|---| | 9.2 (release candidate) | 9.2.0-rc1 | 9.2.0-rc2 | | 9.1 | 9.1.2 | 9.1.3 | | 9.0 | 9.0.6 | 9.0.7 | | 8.1 | 8.1.10 | 8.1.11 | | 8.0 | 8.0.11 | 8.0.12 | | 7.2 | 7.2.14 | 7.2.15 |

On the Redis side, the 8.4 branch's release notes list Redis 8.4.8, released October 26, 2026, with a fix for a heap buffer overflow when a PUBLISH or SPUBLISH message larger than 4GB is passed over the cluster bus. If you run a different Redis branch, check that branch's release notes for the equivalent release before assuming you're covered.

3. Who can connect and publish?

The attacker needs to be an authenticated client who can publish. That sounds reassuring, but think about who that really is in your setup:

• Every app server, worker and background job that holds the connection password.
• Anyone who can reach the port if the server is exposed to the internet with a weak or shared password.
• Any compromised dependency running inside one of those app servers.

The advisory also notes a detail that matters: with the default proto-max-bulk-len of 512 MB, a client can't send an argument big enough directly. But a Lua script running on the server can build one. So if scripting is available to the client, the size limit alone does not stop this.

What about managed services?

If you use a hosted Redis-compatible service rather than running your own server, the provider usually patches the engine for you. Don't assume it's done, though. Check your provider's security notices or status page for this advisory, and look at the engine version shown in your dashboard. If you can't find a clear answer, ask their support which build you are on.

Self-hosted setups, such as a Docker container on a VPS, a Coolify or Dokploy stack, or a Kubernetes chart, are your responsibility. A container image only gets the fix when you pull the new tag and restart.

A patch plan for a small team

Step 1: Inventory every instance

List every Valkey and Redis server you run: production, staging, preview environments, and the one a developer started months ago and forgot about. For each, note the version, whether cluster mode is on, and whether the port is reachable from outside your private network.

Step 2: Apply the mitigations now if you can't patch today

The Valkey advisory gives two mitigations:

• Use ACLs to block the scripting commands (EVAL, EVALSHA, EVAL_RO, EVALSHA_RO, FCALL, FCALL_RO and FUNCTION) for any user that doesn't need them.
• Don't raise proto-max-bulk-len above its default.

Most apps that only use Redis as a cache or a simple queue never call scripts directly. Some libraries do use them under the hood, for example for rate limiting or job queues, so test in staging before you block scripting in production.

Separately from this bug, make sure the port isn't open to the internet. Bind to a private interface, use a firewall rule or security group, and require a strong password or an ACL user per app.

Step 3: Upgrade with a rolling restart

For a cluster, upgrade one node at a time:

1. Upgrade a replica, restart it, and confirm it rejoins and catches up (INFO replication). 2. Fail over so the upgraded replica becomes the primary for its slots. 3. Upgrade the old primary, which is now a replica. 4. Repeat for each shard, then confirm with CLUSTER INFO that the state is ok.

For a single instance, schedule a short maintenance window. If Redis only holds cache data, the main effect of a restart is a brief cold cache. If it holds sessions or queued jobs, check that persistence (RDB snapshots or AOF) is on before you restart, or users may be logged out and jobs lost.

For Docker, change the image tag to the fixed version, pull it, and recreate the container. Don't rely on a floating tag like latest without checking what version it actually resolves to.

Step 4: Verify

After the upgrade, run INFO server on each node and confirm the version. Watch your error logs and latency for an hour. If your app uses Pub/Sub, send a test message end to end.

Practical takeaways

• Only cluster-mode deployments are affected, so check cluster_enabled first.
• Upgrade Valkey to 9.1.3, 9.0.7, 8.1.11, 8.0.12 or 7.2.15, and Redis 8.4 to 8.4.8, depending on your line.
• If you can't patch yet, block scripting commands with ACLs and keep proto-max-bulk-len at its default.
• Managed services usually patch for you, but confirm the engine version yourself.
• Keep a short written inventory of every data service you run. That turns the next advisory into a 20-minute job instead of a scramble.

---

Not sure what's running on your servers, or which versions? Our Care plans keep caches, databases and runtimes patched and watched. Book a free technical assessment, and we'll list what you're running and what needs updating first.