HowToFixMe
● High · CVSS 7.5 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2017-12231: Cwe-399 in Cisco IOS

⚡ At a glance
Severity7.5 (High) · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
ImpactDenial of service: remote, unauthenticated device crash and reload
Actively exploited?Yes, listed in CISA KEV (added 2022-03-03)
AffectedCisco IOS 12.4 through 15.6 with NAT ALG for H.323 RAS enabled (on by default)
Fixed inNo single fixed build is named in the record, use the Cisco IOS Software Checker in the advisory to find the patched release for your train
Type (CWE)CWE-399: Resource Management Errors

Exploitation status

CVE-2017-12231 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “Cisco IOS Software Network Address Translation Denial-of-Service Vulnerability”, which makes patching mandatory for U.S. federal agencies under Binding Operational Directive 22-01. Federal agencies were required to remediate it by . If you run an affected system, treat this as an emergency change, not a scheduled one.

Exploitation profile: CISA's own SSVC assessment marks this vulnerability as Exploitation: active and Automatable: yes. That combination matters here. the attack is a single crafted IPv4 H.323 RAS packet sent through the device, requires no authentication and no user interaction, and can be scripted to hit many routers in sequence. Treat working attack traffic as certain and patch on an emergency timeline.

Authoritative references:

WARNING: This vulnerability is on the CISA Known Exploited Vulnerabilities catalog (added 2022-03-03). Federal civilian agencies must remediate by 2022-03-24. Treat it as active exploitation, not theoretical.

What is CVE-2017-12231?

CVE-2017-12231 is a denial-of-service flaw in the Network Address Translation (NAT) feature of Cisco IOS. When a Cisco IOS device performs NAT, it runs an application layer gateway (ALG) that rewrites embedded addresses inside certain protocols so the protocol still works through the translation. One of those protocols is H.323, the signalling stack used by older video-conferencing and VoIP gear, and specifically its Registration, Admission, and Status (RAS) sub-protocol.

The bug is in how the NAT ALG translates H.323 RAS messages carried in IPv4 packets. A malformed RAS message is processed incorrectly, and that mishandling crashes the device, which then reloads. Cisco classifies the root cause as CWE-399 (Resource Management Errors). An unauthenticated, remote attacker only has to send a single crafted H.323 RAS packet through an affected device, the attacker does not need to log in and does not need any credential. The CVSS 3.1 vector, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, captures this exactly: network reachable, low complexity, no privileges, no user interaction, and the entire 7.5 score comes from the availability impact (A:H). There is no confidentiality or integrity loss; nothing is read or modified. What you get is an outage, and if the attacker keeps sending the packet, a repeating crash-and-reload loop.

Two facts make this worse than a typical DoS. First, the NAT ALG for H.323 RAS is enabled by default: you do not have to turn anything on to be exposed; you have to turn it off to be safe. Second, the vulnerability is on the CISA Known Exploited Vulnerabilities catalog, so this is being used against real networks, not just discussed in advisories. Cisco tracks the fix under Bug ID CSCvc57217.

Am I affected?

You are in scope if you run Cisco IOS in the 12.4-through-15.6 range and the device performs NAT with the H.323 ALG active. Check the IOS version first:

# On the device, in enable mode
show version | include (IOS|Version)

If the train falls inside 12.4–15.6, confirm whether the device is actually doing NAT and whether the H.323 ALG is engaged:

# Is NAT configured at all?
show running-config | include ip nat

# Are the H.323 NAT ALG services running? (these are on by default)
show running-config | include ip nat service
# Look for the ABSENCE of:  no ip nat service h225
#                           no ip nat service ras

If NAT is configured and you do not see no ip nat service ras / no ip nat service h225 in the config, the default-on H.323 ALG is active and the device is exposed. The authoritative way to confirm whether your exact maintenance release is fixed is the Cisco IOS Software Checker linked in the advisory below.

How to fix CVE-2017-12231

The real fix is to upgrade Cisco IOS to a release that Cisco has corrected for this bug. The CVE record does not name a single “fixed in X” build, because the first fixed maintenance release differs per IOS train. Do not guess a version number, look yours up.

  1. Open the advisory and run the Software Checker. Go to cisco-sa-20170927-nat. The advisory hosts the Cisco IOS Software Checker. enter your exact release string (for example 15.4(3)M) and it returns the first fixed release for that branch.
  2. Stage the fixed image. Download the fixed IOS image for your platform from Cisco (a valid service contract or Smart Account is required), and place it on a reachable TFTP/FTP/SCP server.
  3. Back up, load, and reboot into the fixed image during a maintenance window. The IOS commands below show the standard upgrade path.
# Run from the device console / SSH session, in enable mode
enable
copy running-config startup-config        ! save current config

! copy the fixed image onto local flash (adjust source as needed)
copy tftp://10.0.0.5/<fixed-image>.bin flash:

! verify the image landed and the checksum is good
verify flash:<fixed-image>.bin

! point the boot loader at the fixed image
configure terminal
 boot system flash:<fixed-image>.bin
 end
write memory

! reload into the fixed image (will drop the device for a few minutes)
reload

Replace <fixed-image> with the actual filename of the release the Software Checker told you to install. After the reload, re-run show version and confirm the device booted the fixed build.

If you can't patch immediately

If you cannot schedule an IOS upgrade right away, Cisco's recommended workaround is to disable the H.323 NAT ALG. If your network does not carry H.323 video/voice signalling through this device, this removes the vulnerable code path with essentially no downside. If you do run H.323 through NAT, this can break that traffic, so test it in a window, it is a stopgap, not the fix.

# Disable the H.323 / H.225 / RAS NAT application layer gateway
configure terminal
 no ip nat service h225
 no ip nat service ras
end
write memory

! confirm the services are now off
show running-config | include ip nat service

Beyond disabling the ALG, treat the management and NAT-facing interfaces with the usual hygiene: restrict who can reach the device's control and management planes, and drop unexpected H.323 RAS (UDP/1719) traffic at the edge with an infrastructure ACL where it has no business arriving. None of these replace running a fixed IOS release.

How to verify the fix worked

There is nothing to check in a Linux package manager or Windows update list here: this is router/switch firmware, so every verification step runs on the device itself.

# 1. Confirm the running IOS build matches the fixed release from the Software Checker
show version | include (IOS|Version)

# 2. If you applied the workaround instead, confirm the ALG is off
show running-config | include ip nat service
#   expected lines present:  no ip nat service h225
#                            no ip nat service ras

# 3. Confirm the device is stable and not in a crash/reload loop
show version | include uptime
show logging | include CRASH|RELOAD

The device is remediated once show version reports a build at or above the fixed release Cisco's checker returned for your train, and the uptime is steadily climbing (not resetting every few minutes from repeated crashes). If you only applied the workaround, the device is mitigated, not fixed. until the IOS upgrade lands.

Is this remote code execution?

No. CVE-2017-12231 is purely a denial of service. The CVSS vector shows C:N/I:N/A:H, no data is read or changed; the device crashes and reloads. The danger is availability: an attacker who keeps sending the crafted H.323 RAS packet can hold your router in a reboot loop.

Why is a router crashing scored as high (7.5)?

Because the attack is trivial to reach and trivial to run. It is network-reachable with no authentication, no user interaction, and low complexity, and a single packet takes the device down. For an edge router doing NAT, that is a full outage triggered remotely, which is why the availability-only impact still rates HIGH.

I don't use H.323: am I still exposed?

Quite possibly, because the H.323 RAS NAT ALG is enabled by default whenever the device does NAT. You may never have configured H.323, yet the vulnerable ALG is still parsing those packets. That is exactly why disabling ip nat service h225 and ip nat service ras is a clean workaround for most networks.

Where is the patched version number?

The CVE record does not publish a single fixed build because it varies by IOS train. Use the Cisco IOS Software Checker inside advisory cisco-sa-20170927-nat with your exact release string to get the first fixed maintenance release for your branch.

References

Written by Sai Kiran Pandrala on 2026-05-25. Always confirm against the vendor's advisory before applying changes in production.

Operational notes for this NAT DoS

The trait that makes CVE-2017-12231 awkward in production is that it lives in a default-on feature most operators never deliberately enabled. The H.323 RAS NAT ALG ships active, so a router that has done NAT for years, and has never once intentionally carried H.323 video or voice. is still parsing the very packets that trigger the crash. That is why the disable-the-ALG workaround is so attractive: for the majority of NAT deployments, H.323 inspection is dead weight, and turning it off closes the hole with no functional loss.

If H.323 signalling genuinely transits the device, the calculus changes. Disabling ip nat service h225 and ip nat service ras will break NAT traversal for those calls, so the workaround is a maintenance-window decision rather than a free one. In that case prioritise the IOS upgrade and use an edge ACL to limit which sources can send H.323 RAS (UDP/1719) to the box while the upgrade is staged.

One verification trap worth calling out: because the impact is a crash-and-reload, the symptom of an unpatched, actively-attacked device is an uptime counter that keeps resetting and %RELOAD entries in the log. If you see those after applying the fix, you either booted the wrong image or the boot variable still points at the old build, re-check show version and the boot system line before assuming the patch failed. The Cisco IOS Software Checker on the advisory page, not a third-party aggregator, is the authoritative source for the fixed release on your specific train.

Other flaws in this area worth reviewing while you patch this one:

People also ask

Is CVE-2017-12231 a remote code execution flaw?

No. It is a denial-of-service vulnerability (CWE-399, CVSS 7.5, vector A:H with C:N/I:N). A crafted H.323 RAS packet processed by the NAT ALG crashes and reloads the device. No code execution, no data disclosure: but a sustained attack keeps the router rebooting.

Which Cisco IOS devices are affected, and is the feature on by default?

Cisco IOS 12.4 through 15.6 are affected when the device uses a NAT application layer gateway for H.323 RAS messages. That ALG is enabled by default, so any IOS device doing NAT in that range is exposed unless H.323 inspection was explicitly disabled. Cisco Bug ID CSCvc57217 tracks the fix.

There is no fixed version listed, how do I find the patched release?

The record does not name a single fixed build because the patched train depends on the release you run. Open advisory cisco-sa-20170927-nat and use the Cisco IOS Software Checker: enter your exact train (for example 15.4(3)M) and it returns the first fixed maintenance release for your branch.

Can I mitigate without upgrading IOS?

Yes, temporarily. If H.323 inspection is not needed, disable the NAT ALG with no ip nat service h225 and no ip nat service ras. This can break legitimate H.323 traffic that relies on NAT translation, so validate in a maintenance window. It is a stopgap. upgrade to a fixed IOS release for the real fix.