redis-parser CVE-2026-93435: Unbounded Recursion in RESP Parsing Crashes ioredis Clients
redis-parser, the RESP protocol parser for Node.js used by ioredis, does not check the nesting depth of incoming Redis replies. CVE-2026-93435 (CVSS 7.5 under v3.1, 8.7 under v4.0) describes how a malicious or compromised Redis endpoint can trigger a stack overflow in the client process using deeply nested array replies, crashing it. Affected are redis-parser versions up to 3.0.0. No official fix had been released at the time of writing.
TL;DR — 90 seconds
The RESP parser in redis-parser, which ioredis uses for the Redis protocol, processes nested array replies recursively without limiting depth. If a Redis server replies with a heavily nested array, Node.js throws a RangeError: Maximum call stack size exceeded and the client process crashes. An attacker needs control over the Redis server, or the ability to tamper with its replies, for example via a compromised or spoofed Redis endpoint. No fix has been released so far; ioredis maintainers have acknowledged the problem.
What is the problem?
redis-parser is the RESP protocol implementation that node_redis and ioredis originally built on, and that ioredis still uses today. RESP array replies can be nested, for example an array of arrays. The parser handles this nesting through recursive function calls, one per nesting level, without enforcing a maximum depth.
ioredis passes incoming socket data straight into parser.execute(data). If the connected Redis server, or an attacker posing as one, replies with an array nested many thousands of levels deep, the recursion exhausts the Node.js call stack. The result is an uncontrolled crash of the client process via a RangeError exception that ioredis currently does not convert into controlled error handling.
Who is affected?
Affected are applications that use ioredis with a vulnerable redis-parser version and process replies from a Redis server that is not fully trusted, for example in SSRF-like setups, compromised Redis instances, or connections over unauthenticated network segments.
| CVE | Package | Affected | Fix | CVSS |
|---|---|---|---|---|
| CVE-2026-93435 | redis-parser (dependency of ioredis) | redis-parser ≤ 3.0.0 | not yet released | 7.5 / 8.7 |
Exactly how many current ioredis versions still pull in the vulnerable redis-parser version could not be conclusively determined from the available sources at the time of writing. Check your own dependency resolution with npm ls redis-parser.
Impact
A successful attack terminates the Node.js process holding the Redis connection in an uncontrolled way. For applications without process supervision, such as PM2, systemd with a restart policy, or an orchestrator like Kubernetes, this means a complete outage of the affected service, not just the Redis connection.
Confidentiality and integrity are not affected as far as is currently known; this is a pure denial-of-service vulnerability. Since ioredis is a central dependency in many Node.js backends for sessions, caching and queues, the outage can still have cascading effects on dependent services.
Mitigation / Immediate actions
No official fix was available at the time of writing. Until then: make sure your Node.js process runs under process supervision, such as systemd, PM2, or a Kubernetes restart policy, so a crash leads to an automatic restart rather than a lasting outage.
Restrict which Redis endpoints your application is allowed to contact, especially for user-controlled connection targets. Terminate Redis connections over TLS with certificate verification where possible, so no arbitrary endpoint can pose as your Redis server. If your setup allows it, consider switching to a Redis client that implements RESP3 natively without the affected redis-parser library.
Detection / Verification
Monitor your Node.js processes for unexpected restarts or crashes with RangeError: Maximum call stack size exceeded in the stack trace, especially when it originates from the redis-parser or ioredis module.
Check whether your Redis connections are actually established only to trusted Redis instances under your own control. Particularly suspicious are connections to Redis endpoints whose reply behavior has recently changed, or unusually large reply packets immediately before a crash.
Operator recommendation
Act today if: your application uses ioredis and connects to Redis instances that are not fully under your own control, for example in multi-tenant setups or user-controlled configurations. Set up process supervision and network restrictions immediately.
Monitoring is enough if: your Redis instances run only internally and under your own control, and process supervision is already in place. Track the fix release and schedule the update.
Frequently asked questions about CVE-2026-93435
Is node_redis (the official Redis client) also affected?+
Current major versions of node_redis (v4 and later) use their own RESP3 parser and no longer the historical redis-parser package. If in doubt, check your own dependency resolution.
Is process supervision enough as a permanent fix?+
Process supervision prevents a lasting outage but does not fix the underlying vulnerability. Every restart briefly interrupts active connections and requests. A patch remains necessary once available.
Do I just need to secure my own Redis server, or is that not enough?+
Your own trusted Redis server does not trigger the issue. It becomes critical when your application connects to Redis endpoints that an attacker can control or spoof.
Was a CVE assigned against ioredis itself?+
No. CVE-2026-93435 is assigned against the redis-parser dependency. The related ioredis issue #2108 documents the effect on ioredis applications.
Is there a workaround without a code change?+
An upstream proxy or network policy that restricts connections to known, trusted Redis endpoints reduces the risk without a code change. It does not replace a patch, though.
Conclusion
This case is a reminder that protocol parsers for network services should generally assume untrusted input, even when the counterpart is usually one's own infrastructure. Unbounded recursion in a widely used but rarely scrutinized dependency like redis-parser is enough to take down production Node.js services.
Sources
I help harden Node.js backends against denial-of-service vulnerabilities in dependencies and set up resilient process supervision for Redis-backed services.
Dependency audits for Node.js and PHP stacks, process-supervision and restart-policy setup, network segmentation for database connections.
Platform operations, not paper advice: I review, patch and harden your infrastructure on an ongoing basis.