The Redis Service Count Cannot Identify Valkey Cluster Mode
Valkey fixed an integer-truncation heap overflow in cluster publish message construction. An authenticated client that can publish to a channel in cluster mode can create a message larger than 4 GiB through server-side scripting and trigger a buffer overflow. Patched versions include 7.2.15, 8.0.12, 8.1.11, 9.0.7, 9.1.3, and 9.2.0-rc2.
Public search has a naming problem for this issue. Valkey uses the Redis protocol and may be classified by service rather than by the product name.
Observation
On November 14, 2026, app="Valkey" returned zero results. service="redis" returned 3,197,761. Both count-only queries succeeded with sub_type=all, page 1, and page size 1.
The application match found no result for the exact product label in this query scope. The service match found assets exposing the Redis service label. The latter population can include Redis, Valkey, forks, proxies, and services whose banners resemble the protocol. It does not identify server implementation, version, authentication policy, or cluster mode.
Read the vulnerability correctly
The flaw is not reachable by every network client. It requires authentication, the ability to publish, and cluster mode. A script can construct a channel and message that exceed UINT32_MAX even when the normal bulk limit prevents a client from sending one argument that large. The server truncates the serialized length when it allocates the cluster message block.
Use the service count to find public Redis-compatible endpoints and to check whether they should be exposed. Use an authenticated local inventory to distinguish Valkey from Redis and to record version, cluster mode, ACLs, and scripting permissions. A product name search cannot answer those questions.
Remediation path
Upgrade every cluster node to a patched release and verify the version after the rolling restart. Restrict EVAL, EVALSHA, FCALL, and FUNCTION commands through ACLs when the application does not need them. Keep proto-max-bulk-len at its default. Review custom users and publish permissions, then rotate credentials for any client that could have been used to submit oversized messages.
Monitor node crashes, memory pressure, and unexpected cluster message errors. Preserve logs from the upgrade window and check that replicas and nodes that carry no current application traffic are also updated.
Reporting limits
The correct statement is that there were zero app-field observations for the exact Valkey label and more than three million Redis service observations on that date. The service count is not a Valkey count, and it is not a count of vulnerable cluster nodes. Keep those limits in the article so the reader can use the measurement as a lead rather than a verdict.
Top comments (0)