Is CVE-2017-12231 (Cisco IOS Software Network Address Translation Denial-of-Service) being exploited in the wild?

Yes. CISA added CVE-2017-12231 to its Known Exploited Vulnerabilities catalogue on 3 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. A vulnerability in the implementation of Network Address Translation (NAT) functionality in Cisco IOS could allow an unauthenticated, remote attacker to cause a denial of service.

What the KEV listing tells you about exploitation status

CISA’s KEV catalogue is the practical signal that matters here: if a CVE is listed, defenders should treat it as actively exploited rather than merely theoretically vulnerable. For CVE-2017-12231, that means the question is no longer whether the flaw can be abused, but whether your Cisco IOS estate still exposes the NAT path and whether exposed devices have already been targeted.

That distinction matters because denial-of-service on infrastructure equipment is often used for disruption, service degradation, or as a precursor to broader network pressure. For edge devices and routers, even a short interruption can affect downstream services, remote access, and incident response visibility. The relevant operational question is therefore exposure plus blast radius, not just patch status.

How to confirm whether you are exposed

Start by identifying every Cisco IOS device that uses NAT and every internet-facing or remotely reachable management path around it. The most common mistake is assuming only core routers matter, when edge appliances and branch devices can be equally important if they perform NAT in production traffic flows.

Confirm the exact IOS software footprint, the presence of NAT functionality, and whether the device is reachable from untrusted networks or through partner links. The CISA Known Exploited Vulnerabilities Catalog should be used alongside the vendor advisory and your asset inventory to verify whether the device is in scope for remediation.

If you need a broader remediation view for this sort of issue, the Edge Device Security Guide is useful because it frames router and gateway exposure as an asset, logging, and hardening problem rather than a single-device patching task.

What to do when patching cannot happen immediately

If the device cannot be updated at once, reduce exposure first. Restrict management access, remove unnecessary reachability, segment the device from untrusted networks where possible, and treat NAT-capable routers as high-priority infrastructure assets until the remediation window closes. For active exploitation cases, containment is often more important than trying to preserve convenience.

Review logs for unusual restarts, forwarding disruptions, configuration changes, or repeated malformed traffic against the device. If the router or gateway has been exposed for some time, assume the device may have been probed already and preserve relevant logs before making intrusive changes. When a control-plane denial of service is involved, availability loss can hide the first signs of compromise or misuse.

Use the Zero-Day and Exploited Vulnerabilities Guide as a decision aid for emergency triage, because active exploitation changes the order of operations: exposure reduction, mitigation, and verification come before long-cycle cleanup.

What to check after remediation

After mitigation or patching, validate that NAT traffic still behaves normally, that the device remains stable under load, and that no adjacent services were impacted by the change. A denial-of-service flaw on infrastructure gear can create secondary problems, including routing instability, session drops, and monitoring blind spots, so post-change verification should be explicit rather than assumed.

Check whether the device was a single point of failure for a branch, site, or remote access path. If so, document the dependency and consider whether failover, redundancy, or a different traffic design is needed. In this class of issue, resilience is part of the fix, not an afterthought.

If you want a structured way to turn KEV-listed findings into action, the Vulnerability Management Guide helps tie prioritisation, exception handling, and verification to an actual remediation workflow rather than a one-time patch event.

Risk and Threat Considerations

Internet-facing routing and NAT functions are high-value targets because they sit on the traffic boundary and can affect both availability and visibility. Once a flaw is known to be exploited in the wild, the risk is no longer abstract, any unremediated device becomes a candidate for disruption or a repeated probe path.

Failure mechanism: An unauthenticated remote request can trigger a denial of service in the NAT implementation, which can exhaust or destabilise the forwarding plane and interrupt legitimate traffic.

Impact: The affected router or edge device may stop forwarding correctly, causing service interruption, management loss, and downstream business outages until the device is recovered or replaced.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploits require rapid identification and remediation prioritisation.
Recommendation — Prioritise and remediate KEV-listed devices using continuous vulnerability management.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The issue calls for confirming exposure and tracking an actively exploited CVE.
	SI-2 — Flaw Remediation	Active exploitation makes timely remediation and mitigation the core control response.
Recommendation — Scan, track, and remediate affected Cisco IOS assets under RA-5. Apply mitigations or patches promptly and document exceptions under SI-2.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and recorded	You must identify which Cisco IOS assets expose NAT and are vulnerable.
	PR.DS-01 — Data-at-rest is protected	Not selected because it does not materially support this answer.
Recommendation — Identify affected devices and record the exposed NAT vulnerability. Omit

Practitioner Guidance

What to prioritise: Treat KEV-listed infrastructure flaws as asset-driven work, not ticket-driven work. Prioritise internet-facing devices, branch gateways, and any Cisco IOS deployment where NAT is part of production traffic handling.

What to verify: Confirm both software exposure and operational dependence. A device that is technically vulnerable but isolated may be lower risk than a device that fronts critical remote access or site connectivity.

Practitioner takeaway: For exploited edge-device CVEs, the key decision is whether you can reduce exposure and prove stability quickly, because availability loss on routers is itself a security outcome, not just an inconvenience.