CVE-2022-20821

What it actually does

This vulnerability is a Cisco IOS XR Software misconfiguration introduced by the health check RPM: when activated, it opens TCP port 6379 and exposes a Redis instance running inside the NOSi container to unauthenticated remote network access. An attacker who can reach that port can connect directly to Redis, read database information, write to the Redis in-memory database, and use Redis file-writing capabilities to write arbitrary files within the container filesystem. Cisco describes the Redis instance as sandboxed, so successful exploitation is not expected to provide remote code execution or compromise the integrity of the IOS XR host operating system, but it does affect confidentiality and integrity inside the containerized component.

Why it matters to the business

Affected Cisco routing platforms may expose an internal Redis service to the network, allowing outsiders to tamper with container data or retrieve operational information without credentials. Because this issue is in CISA KEV, has documented active exploitation, and had a federal remediation deadline of 2022-06-13, internet- or untrusted-network-facing IOS XR devices should be treated as high-priority even though the CVSS score is moderate. The main operational risks are unauthorized access to internal service data, unexpected device/container behavior, increased incident response workload, and potential use of exposed infrastructure as a foothold for reconnaissance against network management planes.

How an attack unfolds

An attacker first identifies Cisco IOS XR systems with TCP/6379 reachable from their network position, commonly through scanning or targeted probing of routing infrastructure. If the health check RPM has activated the vulnerable behavior, the attacker connects to the Redis service without authentication. From there, they can issue Redis commands to inspect keys and configuration, retrieve data from the in-memory database, modify values, or attempt to write files into locations permitted by the Redis process inside the NOSi container. The sandboxed container limits impact to the container context and prevents direct remote code execution or host IOS XR integrity compromise as described by Cisco, but the exposure still enables unauthorized read/write access to an internal service. Known active exploitation means defenders should assume opportunistic scanning and attempted Redis interaction may have occurred wherever TCP/6379 was reachable.

How to fix it

Upgrade affected Cisco IOS XR Software to a Cisco-recommended fixed or non-vulnerable release for the relevant platform, using Cisco’s official advisory and Software Checker to identify the exact target release because fixed versions were not provided in the input. If immediate upgrade is not possible, remove or disable the vulnerable health check RPM where operationally safe and supported, and ensure TCP/6379 is not reachable from untrusted networks. Apply infrastructure access controls so Redis is accessible only from explicitly required management or internal control-plane sources, preferably not externally reachable at all. Use device ACLs, infrastructure firewalls, control-plane policing, and management-plane segmentation to block unsolicited access to TCP/6379. After remediation, review whether any exposed Redis data or container files may have been modified and consider restoring affected container state from trusted sources if tampering is suspected.

How to confirm the fix worked

Confirm the installed Cisco IOS XR release and health check RPM status against Cisco’s advisory and Software Checker. From an authorized external vantage point, verify TCP/6379 is closed, filtered, or otherwise inaccessible; a Redis banner or successful Redis command response indicates remaining exposure. From allowed management zones, confirm that Redis is not listening on unintended interfaces and is not reachable without authentication unless explicitly intended and protected. Validate that ACLs or firewalls deny inbound TCP/6379 from untrusted sources. Review post-upgrade or post-mitigation device behavior to ensure the health check function is either updated, disabled, or no longer opening Redis by default.

Typical attack path

1. Scan for Cisco IOS XR devices or network infrastructure exposing TCP port 6379.
2. Establish a direct unauthenticated Redis connection to the exposed service.
3. Run Redis discovery commands such as INFO, CONFIG, DBSIZE, KEYS, SCAN, or CLIENT LIST to understand the database and environment.
4. Read Redis keys or other database metadata to collect information.
5. Modify Redis in-memory data or attempt Redis-backed arbitrary file writes within the NOSi container filesystem.
6. Use the access for further reconnaissance, persistence attempts inside the container context, or disruption/tampering of container-resident data.

How to detect it

To determine whether exploitation already occurred, review network flow logs, firewall logs, IDS/IPS telemetry, packet captures, and management-plane access logs for inbound connections to affected IOS XR devices on TCP/6379. Pay particular attention to connections from the internet, untrusted networks, unknown scanners, or sources with no operational reason to contact Redis. If device/container-level logs are available, look for Redis command activity from remote clients, especially INFO, CONFIG, KEYS, SCAN, GET, SET, FLUSHALL, SAVE, BGSAVE, SLAVEOF, REPLICAOF, MODULE, or CONFIG SET dir/dbfilename patterns associated with Redis abuse and file writes. Examine the NOSi container filesystem for unexpected files, recently modified files, or Redis dump/config files in unusual directories. Since this issue is known exploited in the wild, absence of host-level indicators should not be treated as proof of no exploitation if network telemetry is unavailable; prioritize correlation of exposure windows with historical TCP/6379 connection attempts.

• TCP/6379 open on Cisco IOS XR device
• inbound connection to TCP/6379
• Redis protocol traffic to Cisco IOS XR
• redis-cli connection to IOS XR
• ERR unknown command
• NOAUTH Authentication required
• -NOAUTH Authentication required
• +PONG
• +OK
• INFO command received
• CONFIG GET
• CONFIG SET
• KEYS *
• SCAN 0
• CLIENT LIST
• DBSIZE
• GET
• SET
• FLUSHALL
• SAVE
• BGSAVE
• SLAVEOF
• REPLICAOF
• MODULE LOAD
• CONFIG SET dir
• CONFIG SET dbfilename
• dump.rdb
• redis.conf
• /misc/scratch
• /tmp/dump.rdb

What your security team should do

• Immediately inventory Cisco IOS XR devices, especially affected Cisco 8200 and NCS platforms, and identify any systems exposing TCP/6379.
• Prioritize remediation for internet-facing, partner-facing, or broadly reachable management/control-plane interfaces because the issue is in CISA KEV and has active exploitation history.
• Upgrade to a Cisco-advised fixed IOS XR release or apply Cisco-supported mitigations; use Cisco Software Checker to determine platform-specific fixed releases.
• Block TCP/6379 from all untrusted networks using infrastructure ACLs, firewalls, and control-plane protections while upgrades are scheduled.
• Hunt historical network telemetry for inbound connections to TCP/6379 on IOS XR devices, especially before mitigation or upgrade.
• Review Redis/container artifacts for unauthorized Redis commands, unexpected key changes, and suspicious file writes within the NOSi container filesystem.
• Add continuous exposure monitoring for Redis on network infrastructure devices so future regressions or accidental re-exposure are detected quickly.