Yes. CISA added CVE-2022-20821 to its Known Exploited Vulnerabilities catalogue on 23 May 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Cisco IOS XR software health check opens TCP port 6379 by default on activation. Any organisation running the affected product should treat remediation as urgent.
What the KEV listing means for a Cisco IOS XR exposure check
The practical question is not whether a proof-of-concept exists, but whether this flaw has crossed into active exploitation. A KEV listing means CISA has enough evidence to treat the issue as being used in the wild, so defenders should assume exposure is timely and actionable, not theoretical. For this case, the default-open health check behavior around TCP 6379 makes external reachability worth validating immediately.
If you operate Cisco IOS XR, confirm whether the health check feature is enabled anywhere in your fleet and whether the device is reachable from networks that should never see it. The first decision is scope: identify all routers, management paths, and exceptions before you decide whether the issue is a patching job or an incident-response job.
When a device opens a service on a well-known port by default, the attack surface often expands faster than asset inventories do. That is why open-port findings need to be tied to actual device configuration, not just product ownership or version labels.
What to do when remediation is urgent but not yet complete
The correct response is to treat the finding as an exposure reduction exercise, not just a software update ticket. If you cannot patch immediately, constrain reachability first, then verify whether the port is exposed only where it is operationally required. Where possible, use management-plane restrictions, firewall policy, or segmentation to reduce who can talk to the affected service.
Because CISA did not link this CVE to known ransomware campaigns, the response should be driven by confirmed exploitation risk rather than a ransomware-specific playbook. That still means urgent action, but it also means your containment steps should be proportional to the role the device plays in routing, management, and uptime dependencies.
If the affected service was reachable from untrusted networks, review whether logs, configuration state, or management traffic show any abnormal access around the time the exposure existed. For network appliances, compromise indicators are often subtle, so the absence of an alert is not evidence of safety.
How to verify compromise and reduce blast radius
Start by looking for abnormal access to the device, changes to configuration, unexpected processes, or evidence that the exposed port was probed repeatedly. If the device handles routing or management functions, check whether credentials, sessions, or adjacent admin access paths could have been exposed through that trust boundary.
If you find signs that the service was externally reachable before remediation, assume the device may need more than a simple patch cycle. In that situation, preserve logs and configuration evidence, validate whether any privileged access was used recently, and assess whether related credentials or management sessions should be rotated.
Edge Device Security Guide is useful here because the issue sits in the same risk class as exposed management interfaces and internet-facing appliances. Network Ports and Protocols Security Guide helps teams distinguish an ordinary open service from a dangerous one that should never be externally reachable.
Risk and Threat Considerations
Exploitation risk is elevated when a network device exposes a service that was not intended to be reachable from hostile networks. In that scenario, the main concern is not just unauthorized access to one port, but the possibility that the device becomes a foothold into routing, management, or adjacent administrative trust paths.
Failure mechanism: The vulnerable health check opens TCP 6379 by default, so an attacker can probe or interact with an externally reachable service that defenders may not have intended to expose.
Impact: Successful exploitation can lead to unauthorized access, device compromise, or follow-on movement into management paths that support broader network control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Open network services on appliances are a secure-configuration failure. |
| Recommendation — Harden device settings and remove unnecessary exposed services. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | The exposed health check service should not remain enabled unless required. |
| AC-4 — Information Flow Enforcement | Restricting who can reach the port is central to reducing exposure. | |
| SI-2 — Flaw Remediation | The CVE requires urgent remediation once active exploitation is known. | |
| Recommendation — Disable unnecessary services and ports on the device. Enforce network controls that limit access to the service. Prioritise patching and mitigation for the exploited flaw. | ||
Practitioner Guidance
What to verify: Verify actual network exposure, not just whether the product is installed. A device that is patched but still reachable from untrusted networks remains a security problem until the exposure is removed.
Decision rule: If the port was reachable outside an approved management boundary, treat the device as potentially compromised until you have checked logs, configuration integrity, and recent administrative activity. If the service was never externally reachable, focus on hardening and validation rather than incident escalation.
Practitioner takeaway: For actively exploited network-device flaws, the highest-value move is to close the exposure path first, then prove whether the appliance has already been used as an entry point.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2022-20821 (Cisco IOS XR Open Port)?
- CVE-2022-20821 (Cisco IOS XR Open Port)
- Is CVE-2016-6415 (Cisco IOS, IOS XR, and IOS XE IKEv1 Information Disclosure) being exploited in the wild?
- Is CVE-2018-0175 (Cisco IOS, XR, and XE Software Buffer Overflow) being exploited in the wild?