A subtle bug in the widely used Go Redis client library, go-redis, can cause commands to receive
out-of-order responses when the library’s initial identity handshake — the
CLIENT SETINFO command — times out during connection establishment, a flaw tracked as CVE-2025-29923 and fixed in the 9.5.5, 9.6.3, and 9.7.3 releases of go-redis.
Background
The go-redis client is the de facto Redis client library for many Go applications, used in microservices, caching layers, distributed queues, and ephemeral data stores. When a new TCP connection is established to a Redis server, go-redis can optionally send an identity payload using the
CLIENT SETINFO command so the server (and operators) can identify the client. Under normal conditions this is harmless and useful for telemetry and debugging.
CVE-2025-29923 describes a race/timeout condition that occurs when
CLIENT SETINFO times out while the library is still establishing the connection. In those cases, unread bytes from the failed identity exchange can remain in the connection buffer and later be interpreted as the response to a
different command. The result: a caller receives the wrong reply for a command it issued, with surprising and potentially dangerous downstream effects. The issue only manifests under a set of specific but realistic conditions:
- The client is configured to transmit identity (the default behavior unless explicitly disabled).
- There are network connectivity problems between client and server (packet loss, jitter, or transient connectivity drops).
- The application or environment uses aggressive dial/read/write timeouts that make
CLIENT SETINFO more likely to fail.
These preconditions raise the attack complexity, but they do not make exploitation impossible — real-world environments with flaky networks, aggressive timeouts, or complex connection routing can reproduce the scenario.
What the vulnerability actually does (technical overview)
How response ordering normally works
A Redis client issues commands over a TCP stream and expects responses in the same order. The protocol is synchronous in that the Nth response corresponds to the Nth command. Client libraries rely on this ordering guarantee to match replies to the originating call. If bytes intended for one exchange remain on the socket, the next read may consume those bytes, producing an apparent valid response for a different command — which is exactly what went wrong here.
Where go-redis fails
When connection setup sends
CLIENT SETINFO, and that command times out, the library code did not always ensure the connection stream was left in a known, clean state. If part of a response remained unread (or if the read/write timing produced a partially received reply), subsequent application commands could read those leftover bytes and interpret them as valid responses for a later request.
The observable behaviors by usage pattern:
- Sticky (persisted) connections: the bad data can persist for the lifetime of the connection, causing multiple subsequent commands to receive incorrect replies.
- Connection pools (default ConnPool): the pool typically detects unread residual data when returning a connection and will mark the connection as bad and close it, limiting the damage to at most one mis-delivered reply before the connection is discarded.
Practical exploit model
A successful, targeted exploitation attempt requires an attacker to create or amplify the timing/net conditions that cause
CLIENT SETINFO to time out. This could be achieved via:
- Forcing network instability (e.g., manipulating the path or using a man-in-the-middle that delays packets).
- Inducing tight timeouts in client code (misconfiguration or deliberate lowering of timeouts).
- Leveraging normal multi-tenant environments and pipelining to maximize the probability of a mis-ordered response surfacing.
Note that the attacker does not get arbitrary code execution or direct data exfiltration from the Redis server by this flaw alone — the core impact is
integrity (wrong answers) and potential
confidentiality leaks in app logic when responses are applied to the wrong request. The recorded CVSS base score for this CVE is in the
low range (3.7) because of the realistic but non-trivial exploit preconditions and the lack of direct confidentiality impact in isolation.
Confirmed facts and verified details
- The go-redis project reported and fixed the issue; fixed releases are 9.5.5, 9.6.3, and 9.7.3. Upgrade to one of these or later to eliminate the vulnerability in the client library.
- Public vulnerability tracking databases list CVE-2025-29923 and map affected version ranges consistent with the project advisory.
- The issue only occurs when the client transmits identity or is otherwise exposed to a
CLIENT SETINFO exchange that times out, and aggressive timeouts or flaky networks increase the risk.
Where a claim could not be independently verified (for example, a public exploit in the wild that weaponizes this exact sequence against production services), operators should treat the lack of an observed mass-exploit campaign as temporary and not a reason to delay remediation. Public trackers and internal incident reviews as of early December 2025 reported no widespread exploitation, but detection of proof-of-exploit is often delayed and contextual.
Impact: Who should care and why
This vulnerability primarily impacts developers and operators who use go-redis in production services where:
- Redis is part of the control path for application state or authorization decisions.
- Pipelines or multi-command transactions are used heavily.
- Applications rely on the strict ordering of responses (virtually all clients do).
Concrete operational risks:
- Business-logic correctness: commands may receive unrelated responses, causing incorrect decisions, corrupted caches, or incorrect writes based on wrong reads.
- Multi-tenant leakage: in environments where logical separation relies on correct responses, an out-of-order reply could inadvertently expose values to the wrong tenant’s request-handling path.
- Hard-to-trace bugs: intermittent, timing-dependent response mismatches are notoriously difficult to debug and may look like upstream redis or application logic failures.
That said, the flaw does not permit remote code execution on the client or server by itself, and the exploit complexity is higher than many high-severity vulnerabilities — which is why public scoring places the CVSS base in the low range. Nevertheless, the operational impact can be material depending on application semantics and tolerance for inconsistent data.
Reproducing the issue (for testing / validation)
A generic repro pattern used by maintainers and testers is:
- Create a go-redis client with aggressive Dial/Read/Write timeouts.
- Ensure client identity transmission is enabled (default).
- Simulate network delay or packet loss during initial connection establishment so that
CLIENT SETINFO either times out or only partially completes.
- Issue multiple pipelined commands or reuse the same connection repeatedly to observe mis-delivered responses.
Teams should reproduce this in an isolated lab environment only. Reproducing the issue against production services or public endpoints risks service disruption and is not recommended. The public advisories and test cases in the upstream PR provide guidance and small code snippets that demonstrate how an aggressive timeout plus delayed server responses can trigger the bug.
Mitigation and remediation roadmap (practical steps)
Immediate prioritization should follow a typical security triage: Identify, Mitigate, Patch, Verify.
1. Inventory (0–24 hours)
- Identify all service repositories and binaries that import github.com/redis/go-redis/v9.
- For compiled artifacts and containers, locate the module version at build time (go.mod) or inspect binary module info if available.
- Prioritize internet-facing, multi-tenant, or security-critical services.
2. Short-term mitigation (if you cannot upgrade immediately)
- Disable the identity handshake: construct the client with the DisableIdentity flag set to true. This prevents
CLIENT SETINFO from being sent and therefore avoids the specific timeout vector. This is an acceptable temporary workaround for many environments that do not require client identity telemetry.
- Avoid overly aggressive timeouts: increase DialTimeout, ReadTimeout, and WriteTimeout to realistic values for your network environment to reduce false timeouts during connection establishment. This reduces the window where the bug can be triggered.
- Limit connection stickiness: where possible, prefer pooled short-lived connections over sticky long-lived connections until the client library is upgraded. Pooling reduces the number of connections that can persist in a bad state.
- Increase observability: add metrics and logs around Redis command latency, connection errors, and “protocol errors” to spot anomalous mismatches.
3. Upgrade (0–7 days)
- Upgrade go-redis to v9.5.5, v9.6.3, v9.7.3, or later depending on your project’s minor branch, and rebuild all binaries and container images. The upstream fix is included in these releases; move to the closest available fix for your version line.
- After upgrading, run a controlled rollout and regression tests that exercise pipelining, pooled connections, and identity-enabled handshakes.
Suggested commands for module upgrades (example):
- Update the module reference in your module:
- go get github.com/redis/go-redis/v9@v9.7.3
- go mod tidy
- Rebuild and redeploy services following your CI/CD pipeline.
4. Verification and monitoring (post-deploy)
- Run unit/integration tests that simulate networking delays and pipelining to ensure responses remain ordered.
- Monitor application-level metrics for any residual “unexpected response” errors, and validate that connection error rates drop after the upgrade.
- For added confidence, perform controlled fault-injection tests in staging.
Detection guidance
Because the symptom is an application-level logic error rather than a distinct network signature, detection requires correlated telemetry:
- Correlate Redis command response values with expected application state. Unexpected values after a command that should be deterministic are a red flag.
- Alert on increased command latency or transient “protocol” style errors on Redis connections.
- Capture and analyze client-side logs that record both the command issued and the raw reply when anomalies occur — this helps prove an ordering mismatch.
- If your systems capture pcap-level traces or tcpdump around the time of an incident, reconstruct the command/response stream to confirm whether a response belonged to a prior identity exchange. This is forensic and typically requires cooperation between application and network teams.
Windows and cross-platform operators should also ensure their fleet scans (SCA tools) report and prioritize go-redis versions for remediation. The WindowsForum operational guides recommend inventorying binaries and container images and rebuilding artifacts with the patched library where necessary.
Risk assessment and operational trade-offs
Strengths of the vendor response
- The go-redis maintainers identified the bug, produced targeted fixes, and released stable versions that remediate the flaw. Multiple independent vulnerability databases and package advisories ingested the fix, helping downstream packagers and service owners prioritize updates.
Residual risks
- Attack complexity remains non-trivial, but motivated attackers who can influence network conditions or cause tight timeouts may still create the conditions to trigger an out-of-order response in unpatched clients.
- Vendor adoption lag: some downstream packagers, container images, or third-party vendors who embed go-redis may delay publishing updated builds. Inventory and vendor outreach remain necessary.
Business impact considerations
- For many services this is a correctness/integrity issue rather than a catastrophic compromise; however, systems that rely on Redis for authorization decisions or transactional integrity must treat the issue as high priority despite the CVSS numeric score.
- The decision to disable identity as a temporary mitigation should weigh the operational value of
CLIENT SETINFO telemetry versus the risk of mis-ordered responses.
Checklist for Windows administrators and dev teams
- Inventory: find all services that import github.com/redis/go-redis/v9 and record the version in go.mod or build manifests.
- Prioritize: rank services by exposure (internet-facing, multi-tenant, auth-critical).
- Mitigate: if you cannot immediately patch, set DisableIdentity to true and relax overly aggressive timeouts.
- Patch: upgrade to v9.5.5 / v9.6.3 / v9.7.3 or later and rebuild binaries and images.
- Verify: run pipelining and connection-handshake tests in staging before production rollout.
- Monitor: set alerts for anomalous Redis reply values and connection errors; capture application logs for correlation.
- Vendor follow-up: confirm third-party dependencies and base images used in production are rebuilt with patched go-redis.
Final analysis and recommendations
CVE-2025-29923 is a pragmatic reminder that client libraries — not only servers — are part of the attack surface. The vulnerability combines a relatively small code-path issue with realistic network conditions to produce confusing and potentially damaging mis-ordered responses. While the numeric severity is low and the exploit prerequisites elevate complexity, the operational risk can be high for systems that demand strict data integrity or rely on Redis for authorization decisions.
Actionable priorities:
- Treat this as a high-priority patch for applications where Redis influences security or business-critical state.
- Where rapid upgrades are unavailable, apply the DisableIdentity workaround and relax aggressive timeouts as a short-term containment.
- Rebuild and redeploy all affected binaries and container images: in Go ecosystems, source-only changes are insufficient — you must recompile with the fixed module versions to eliminate the vulnerability from deployed artifacts.
Operational vigilance and rapid patching will close the window of exposure. The go-redis project has published fixes and guidance; following the remediation steps above will restore the fundamental ordering guarantees applications rely upon and prevent this class of bug from corrupting application logic.
CVE-2025-29923 is fixed in the releases noted above; organizations that use go-redis should inventory, mitigate, and patch as part of their next maintenance window to avoid intermittent integrity issues that are costly to diagnose and repair.
Source: MSRC
Security Update Guide - Microsoft Security Response Center