CVE-2022-24736 Redis Lua DoS: Patch, Mitigations, and Best Practices

A malformed Lua script that reaches Redis’ embedded interpreter can trigger a NULL-pointer dereference and crash redis-server, a denial‑of‑service flaw tracked as CVE‑2022‑24736 that was fixed upstream in Redis 6.2.7 and 7.0.0; the practical mitigations for environments that cannot immediately patch include blocking SCRIPT LOAD / EVAL with ACLs and restricting who can submit Lua code to Redis.

Background​

Redis ships an embedded Lua interpreter to support server‑side scripting via the EVAL, EVALSHA and SCRIPT LOAD commands. That feature is powerful for atomic multi‑key processing, rate limiting, and cache logic, but it expands the server’s attack surface because user‑supplied code is parsed and executed by the Redis process itself. Prior to the fixes released in the 6.2.7 and 7.0.0 families, a specially crafted Lua script could cause a NULL pointer dereference in Redis’ Lua handling path, which leads to an immediate crash of the redis‑server process. The upstream remediation changes the way Redis prepares and isolates user code (moving it to a safe registry, protecting global tables with readonly semantics, and tightening what user code can modify), closing the NULL dereference trigger and associated risks. The upstream patch was merged as part of a multi‑commit pull request on April 27, 2022.

Why this matters: impact and exploitation model​

Primary impact: availability / denial of service​

The direct, documented impact of CVE‑2022‑24736 is availability: a crafted script causes a NULL dereference and process termination, which for Redis means clients lose service until the instance is restarted. For single‑node deployments, that’s a full service outage. For clustered deployments, the failure can cause role changes, failovers, or reduced capacity depending on your configuration and the presence of automated restart/monitoring. NVD and multiple vendor trackers emphasize the availability impact and classify the weakness as CWE‑476 (NULL pointer dereference).

Attack vector and required access​

Most public advisories characterize the attack vector as local (AV:L) with low privileges required (PR:L) because the attacker needs the ability to submit Lua code — essentially, the attacker must be able to invoke SCRIPT LOAD / EVAL or otherwise cause Redis to compile/execute Lua on the instance. In practice this means:

• An unauthenticated, open‑to‑internet Redis instance that allows EVAL/SCRIPT is an obvious target.
• An authenticated user account on Redis (or another route to call EVAL/SCRIPT) could abuse the flaw.
• Environments that disallow Lua scripts or restrict the EVAL family using ACLs greatly reduce exposure.

Put simply: if an attacker can get your Redis to run an attacker‑controlled Lua payload, they can crash the server. This distinguishes the issue from remote code execution (RCE) — there is no public, authoritative evidence that this NULL dereference led to arbitrary code execution — but repeated crashes produce an operational denial of service and can be weaponized against availability‑sensitive systems. Several distributors and trackers note the absence of confirmed RCE and keep the primary impact as DoS.

What was changed upstream (technical summary)​

The upstream fix is not a single guard check; it is a set of changes that rework how user Lua code is loaded and how global tables are presented to that code:

• Readonly global tables and controlled globals: Redis introduced a mechanism to mark global tables readonly and to present a controlled globals table to user functions so scripts cannot mutate interpreter/global state that other scripts or the server rely on. This prevents scripts from reaching unexpected internal state that previously led to erroneous pointer dereferences.
• Registry isolation of user code: Instead of exposing user code as global functions that can be modified by other scripts, Redis places compiled user functions in a registry that is not writable by regular scripts. This reduces opportunities to influence the Lua runtime in ways that caused the NULL dereference.
• Hardening of the script‑loading path: The pull request and release notes show guard logic and reorganization aimed at eliminating cases where uninitialized or freed pointers might be dereferenced during script load/compile or execution.

Those changes shipped as part of the 6.2.7 and 7.0.0 releases (and subsequent vendor/distribution backports). Operators using earlier versions should treat Lua scripting as a risk until they either patch or apply the listed mitigations.

---

Where organizations are most exposed​

• Publicly reachable Redis instances that accept unauthenticated connections (common in misconfigured deployments) are the highest risk because an attacker can directly call SCRIPT/EVAL without credentials.
• Internal services that accept untrusted input and forward it to Redis scripting interfaces (for example, multitenant platforms or plugin architectures) can be abused by a low‑privilege local user.
• Appliances and vendor products that embed older Redis code may still carry the vulnerable Lua runtime; backporting fixes into embedded products can lag, leaving residual exposure. Distribution packaging and vendor backports vary — some maintainers chose to mark older distribution packages as ignored or hard to backport, so inventory and vendor advisories matter.

How to detect whether you are vulnerable​

• Query your Redis version. Any upstream Redis release older than 6.2.7 (for the 6.x line) or older than 7.0.0 (for 7.x) should be treated as vulnerable until the vendor confirms a backport. Run: redis‑cli INFO SERVER | grep redis_version.
• Audit whether clients call EVAL / EVALSHA / SCRIPT LOAD on your instance. Use Redis MONITOR carefully in a test environment or query logs; production MONITOR can be expensive and noisy.
• Check ACLs and command access: if anonymous users or low‑privilege accounts can call SCRIPT or EVAL, treat that as a high‑priority configuration issue.

Immediate mitigations and hardening (operational guidance)​

If you cannot immediately patch, implement one or more of the following measures in order of impact and feasibility:

• Block SCRIPT LOAD and EVAL via Redis ACLs. Create ACL rules that deny the EVAL and SCRIPT family to users that do not need it. This is the simplest and recommended temporary* mitigation because it prevents arbitrary scripts from being submitted. Note: if your application legitimately relies on Lua scripting, you must prioritize patching rather than blocking.
• Ensure Redis is not exposed to the public internet. Use network controls (firewall, security groups, private subnets) to restrict access to known application servers. Protected‑mode, bind‑address and requirepass are not substitutes for proper network segmentation but are additional layers.
• Require authentication for clients and use strong ACLs. Lock down privileges so only specific service accounts can run scripts.
• If using managed Redis services (cloud provider PaaS), check provider advisories — many providers have already applied the patch or offer options to disable scripting. Contact your cloud provider or check their security notices for the fixed versions or mitigation steps.
• For fleeted environments, apply host-level controls: monitor redis‑server process crashes and service restarts, configure alerts for recurring restarts, and temporarily throttle or isolate problematic hosts to avoid cascade failures during a mass exploitation attempt.

Quick mitigation checklist​

• Inventory: identify Redis instances and versions across the estate.
• Block or restrict SCRIPT/EVAL for instances where scripts are not required (ACL deny).
• Restrict network access to Redis (private subnets, MFA for admin consoles, security groups).
• Schedule a patch window to upgrade to Redis 6.2.7+ or 7.0.0+.
• Monitor for crashes and unusual SCRIPT/EVAL activity during and after the upgrade.

Patching and change management — practical steps​

• Test the upgrade in staging: some applications rely on subtle behavior of the Lua environment. The upstream fix also changed semantics (readonly global tables and removed print in some contexts), so test scripts particularly if they relied on mutating globals or using print. The PR explicitly documents breaking changes (for example, disallowing certain non‑local custom function definitions and removing print); evaluate these against your application scripts.
• Upgrade order for clusters: patch and gracefully restart replica nodes first, promote and fail over as appropriate, then patch masters. Follow your application’s SLA and use quarantined test runs before mass rollout.
• For distribution packages, verify vendor backports: in several distributions the upstream fix was packaged and released with distribution‑specific version numbers; check your distro’s security tracker (Debian, Ubuntu, Red Hat, etc. for the exact fixed package and CVE tagging. Some distributions may mark older packages as ignored because the fix cannot be backported easily.
• If you rely on vendor‑embedded Redis in network appliances or vendor appliances, consult the vendor security advisory — those images are often updated on separate cadences.

Detection and logging: rules and suggestions​

• Log and alert on rapid redis‑server termination and unexpected restarts. Repeated crashes timed to client EVAL calls are a strong indicator of attempted exploitation.
• If you have telemetry for Redis command calls, watch for spikes in SCRIPT LOAD, EVAL, EVALSHA, and SCRIPT FLUSH, particularly from accounts that normally do not run scripts.
• Create a short detection signature for SIEM/IDS covering:
• Presence of EVAL or SCRIPT LOAD commands from unusual source IPs or user accounts.
• redis‑server process exit codes and core dumps appearing in a short time window.
• New, unexpected Lua script hashes being loaded (SCRIPT LOAD response returns SHA1; correlate new SHAs with authorized change windows).
• Where safe and possible, capture failing script bodies in a sandboxed environment for forensic analysis. Do not run attacker scripts on production machines.

Real‑world exposure and vendor responses​

Many public trackers and Linux distribution advisories record the vulnerability and the fixed versions; the consensus is that the issue has been fixed upstream and distributors have rolled updates or backports for supported releases. Some distributors list the CVSS as relatively low (3.3) because exploitation requires the ability to run scripts locally or authenticated access, but other trackers emphasize High availability impact in contexts where availability is critical. The variation is a reminder that CVSS numbers are contextual — the business impact depends on how Redis is used in your environment. Debian maintainers and other distributors noted practical backport challenges: while the fix is small, integration with embedded Lua engines or older distribution kernels and packaging policies can complicate backports; operators should therefore verify that the exact package version installed on their systems contains the fix.

Risk analysis and critical considerations​

Strengths of the Redis response​

• The upstream patch is targeted and well documented; it reduces attack surface by isolating user code and making global tables readonly, which is a principled defensive approach rather than a superficial guard. The PR contains performance tests showing little performance regression for typical workloads.
• Redis’ security team assigned a CVE and integrated the fix into the mainstream 6.2 and 7.0 tree, enabling distributors and managed providers to adopt the fix quickly.

Residual risks and caveats​

• Legacy and embedded deployments: appliances and vendors embedding older Redis versions may lag on updates. These environments often do not follow the same patch cadence as mainstream distributions and require vendor engagement. Inventory and vendor outreach are essential.
• Operational dependency on Lua scripts: organizations that rely heavily on server‑side scripts for logic will face a tradeoff between immediate mitigation (disabling scripts) and business continuity. For those environments, rapid testing and patching is the only safe route.
• Misconfiguration prevalence: despite the fix, many Redis instances remain exposed due to default or weak configurations; the combination of an exploitable service and misconfiguration raises operational risk beyond the pure technical severity recorded in CVSS. Public scans historically find hundreds of thousands of exposed Redis instances; while this CVE is not an RCE, an attacker with other weaknesses could combine faults to escalate impact. Treat CVE‑2022‑24736 as one item in a broader hardening checklist.

Incident response checklist (if you detect exploitation)​

• Isolate the affected host from the network to prevent lateral attempts to crash other Redis nodes.
• If the crash is reproducible, capture the script content, core dump, and any available MONITOR logs in a sandbox for analysis.
• Rotate credentials, especially if unauthenticated access was possible; check ACLs and ensure that only necessary accounts remain permitted to execute scripts.
• Restore service from known‑good images if you suspect state corruption; validate data integrity if data persistence was enabled during the crash window.
• Report the incident to your vendor or managed provider if the Redis instance is part of a hosted service.

Recommendations (prioritized)​

• High priority: patch any Redis instance running a version older than 6.2.7 or 7.0.0 as soon as you can after testing. If your application needs server scripting, perform a functional test of scripts with the new semantics before pushing to production.
• Medium priority: if immediate patching is impossible, restrict SCRIPT/EVAL via ACLs and lock down network access to Redis servers. Audit scripts and their authorship.
• Low priority but important: harden host OS-level monitoring to detect repeated redis‑server crashes and alert on unusual command patterns; apply the principle of least privilege to Redis users.

---

Final assessment​

CVE‑2022‑24736 is not a headline‑grade remote code execution worm‑class bug — it is a robustly documented NULL pointer dereference that translates to a reliable denial‑of‑service for Redis instances that can be instructed to execute crafted Lua. The fix upstream is focused and substantial: it reworks the Lua integration in Redis to remove the problematic attack surface and isolate user code. For most organizations, the operational risk is straightforward: patch quickly or block the EVAL/SCRIPT family, and verify your inventory and ACLs. For high‑availability or embedded appliance operators, the remediation path may require staged testing and vendor coordination because of potential semantics changes and packaging/backport constraints. Additional context on Lua‑embedded runtime risks and memory‑handling bugs helps explain why this class of vulnerability deserves careful operational attention: scripting engines run inside server processes and a single malformed input can translate to an immediate process failure. Treat embedded interpreters as first‑class attack surfaces during architecture, patching, and threat modelling.
Organizations should treat this CVE as a prompt to audit Redis usage, tighten command access, and ensure both upstream and vendor supplied packages are updated to the fixed versions (or that compensating ACL/network controls are in place). The technical fix has been merged and distributed; the remaining work is visible and operational: inventory, test, patch, and monitor.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center