Yes. CISA added CVE-2022-0543 to its Known Exploited Vulnerabilities catalogue on 28 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Redis is prone to a (Debian-specific) Lua sandbox escape, which could result in remote code execution. Any organisation running the affected product should treat remediation as urgent.
What “being exploited in the wild” means for this Redis issue
The key point is that this is not just a theoretical vulnerability notice. CISA’s KEV inclusion means there is reliable evidence of active exploitation, so the practical question is exposure, not debate. For a Redis deployment, the right first step is to confirm whether any Debian-based instance is in scope and whether it is exposed in a way that makes exploitation plausible.
That distinction matters because exploited vulnerabilities move from ordinary patch hygiene into incident-prevention work. If the service is reachable from untrusted networks, used by multiple applications, or embedded in infrastructure where operators do not have clean asset visibility, the attack surface can be larger than the Redis team expects.
The safest operational assumption is that KEV-listed weaknesses deserve the same treatment as a live intrusion risk until proven otherwise. For prioritisation, CISA Known Exploited Vulnerabilities Catalog should be used as the trigger for urgent remediation, while NIST National Vulnerability Database remains the reference point for vulnerability record details and product context.
If you need a broader operating model for this kind of response, NHIMG’s Zero-Day and Exploited Vulnerabilities Guide covers the same triage problem: KEV-driven urgency, emergency mitigation, and post-patch validation.
Why the Debian-specific Lua sandbox escape is dangerous
The vulnerability is significant because a sandbox escape changes the security boundary, not just the application behaviour. Redis is designed to process data and commands quickly, but once Lua execution can break out of its intended confinement, the issue can become remote code execution rather than a simple service fault.
That shift in impact is what makes the issue operationally serious. A code execution flaw in an exposed data service can become a bridge to system-level compromise, pivoting, data theft, or downstream abuse of the host. Even where the original vulnerable component looks narrow, the blast radius often extends to the machine, its local secrets, and any internal network reach it already has.
For technical context, the official CVE Program provides the canonical vulnerability identifier and record structure, while Redis-specific remediation details should be confirmed in the vendor advisory rather than inferred from secondary summaries.
When a Redis deployment is part of a larger application stack, the real risk is often not Redis alone but everything that trusts it. That includes cached credentials, session data, internal service endpoints, and any automation that assumes the instance is internal-only and therefore low risk.
How to verify exposure and decide whether to treat it as an incident
First verify whether the affected Redis package and deployment pattern are actually present, then establish whether the service was exposed to untrusted input or reachable from a network path you would not consider safe. In practice, exploitability depends as much on deployment shape and network reachability as on the vulnerability entry itself.
If the instance is internet-facing, if it supports multi-tenant or shared access, or if you cannot confidently account for all command paths into it, treat the situation as higher urgency. If patching or package replacement must wait, isolate the service, reduce reachable interfaces, and look for signs of prior compromise before assuming the system is clean.
Because active exploitation is already confirmed, it is reasonable to check for unusual process creation, modified startup scripts, unexpected outbound connections, and any signs that the Redis host was used as a foothold. The FIRST EPSS resource can help with broader prioritisation, but KEV status should already place this issue in the urgent queue.
If your vulnerability process is mature, NHIMG’s Vulnerability Management Guide is the natural companion for confirming scope, exception handling, and post-remediation verification.
Risk and Threat Considerations
Because this CVE is already in KEV, the main risk is not hypothetical exploitation, but unobserved compromise of systems that were assumed to be routine infrastructure. Redis often sits close to sensitive application data, so exploitation can create immediate exposure even when the service itself is not the final target.
Failure mechanism: A Debian-specific Lua sandbox escape can let an attacker break out of the intended execution boundary, gain code execution on the host, and then use that foothold to access local data, pivot further, or persist.
Impact: The likely consequences include host compromise, theft or misuse of local secrets, service disruption, and downstream access to systems that trust the Redis server or the network segment it occupies.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-09 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Actively exploited Redis exposure needs monitoring for compromise indicators. |
| RS.MA-01 — Response Plan Execution | KEV-listed exploitation calls for urgent containment and remediation execution. | |
| Recommendation — Monitor the host for unusual processes, connections, and software after exposure is confirmed. Execute the incident response plan to contain and remediate the vulnerable Redis instance. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | Exposure confirmation and urgency depend on vulnerability discovery and verification. |
| SI-2 — Flaw Remediation | The issue requires prompt patching or mitigation once confirmed. | |
| Recommendation — Scan affected assets and verify the vulnerable Redis deployment is identified in scope. Apply the vendor fix or approved mitigation to the affected Redis hosts without delay. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV status makes vulnerability prioritisation and remediation central to the answer. |
| Recommendation — Prioritise the Redis flaw as an actively exploited vulnerability and remediate it immediately. | ||
Practitioner Guidance
What to prioritise: Put every exposed or production Debian-based Redis instance into urgent remediation, then separate the work into confirmation, containment, patching, and post-fix validation. Do not wait for proof of abuse before starting response actions when the vulnerability is already KEV-listed.
What to verify: Confirm package lineage, deployment ownership, network reachability, and whether the host stores or can reach sensitive credentials, tokens, or internal services. If the instance cannot be clearly scoped, assume the blast radius is larger than the initial inventory suggests.
Practitioner takeaway: For KEV-listed flaws, the question is no longer whether exploitation is possible, but whether you can still prove the affected service was isolated, patched, and not already used as an entry point.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2022-0543 (Debian-specific Redis Server Lua Sandbox Escape)?
- CVE-2022-0543 (Debian-specific Redis Server Lua Sandbox Escape)
- Is CVE-2022-43939 (Hitachi Vantara Pentaho BA Server Authorization Bypass) being exploited in the wild?
- Is CVE-2022-22948 (VMware vCenter Server Incorrect Default File Permissions Vulnerability) being exploited in the wild?