GHSA-92cp-5422-2mw7
LOWgo-redis allows potential out of order responses when `CLIENT SETINFO` times out during connection establishment
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/redis/go-redis/v9🐹github.com/redis/go-redis/v9🐹github.com/redis/go-redis/v9Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Impact
The issue only occurs when the CLIENT SETINFO command times out during connection establishment. The following circumstances can cause such a timeout:
- The client is configured to transmit its identity. This can be disabled via the
DisableIndentityflag. - There are network connectivity issues
- The client was configured with aggressive timeouts
The impact differs by use case:
- Sticky connections: Rather than using a connection from the pool on-demand, the caller can stick with a connection. Then you receive persistent out-of-order responses for the lifetime of the connection.
- Pipelines: All commands in the pipeline receive incorrect responses.
- Default connection pool usage without pipelining: When used with the default ConnPool once a connection is returned after use with ConnPool#Put the read buffer will be checked and the connection will be marked as bad due to the unread data. This means that at most one out-of-order response before the connection is discarded.
Patches
We prepared a fix in https://github.com/redis/go-redis/pull/3295 and plan to release patch versions soon.
Workarounds
You can prevent the vulnerability by setting the flag DisableIndentity (BTW: We also need to fix the spelling.) to true when constructing the client instance.
Credit
Akhass Wasti Ramin Ghorashi Anton Amlinger Syed Rahman Mahesh Venkateswaran Sergey Zavoloka Aditya Adarwal Abdulla Anam Abd-Alhameed Alex Vanlint Gaurav Choudhary Vedanta Jha Yll Kelani Ryan Picard
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/redis/go-redis/v9 | ≥ 9.7.0-beta.1&&< 9.7.3 | 9.7.3 |
| 🐹Go | github.com/redis/go-redis/v9 | ≥ 9.6.0b1&&< 9.6.3 | 9.6.3 |
| 🐹Go | github.com/redis/go-redis/v9 | ≥ 9.5.1&&< 9.5.5 | 9.5.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/redis/go-redis/v9. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/redis/go-redis/v9 to 9.7.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-92cp-5422-2mw7 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-92cp-5422-2mw7 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-92cp-5422-2mw7. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-92cp-5422-2mw7 in your dependencies?
O3 detects GHSA-92cp-5422-2mw7 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.