How to Fix CVE-2016-6415: Exposure of Sensitive Information to an Unauthorized Actor
| Severity | CVSS 7.5 - High |
|---|---|
| Actively exploited? | Yes, listed in CISA KEV (added 2023-05-19) |
| Affected | Cisco IOS / IOS XE / IOS XR (IKEv1) IOS 12.2-12.4 and 15.0-15.6, IOS XE through 3.18S, IOS XR 4.3.x/5.0.x-5.2.x, PIX before 7.0 |
| Fixed in | See vendor advisory for the patched build |
| Type (CWE) | CWE-200 Exposure of Sensitive Information to an Unauthorized Actor |
Exploitation status
CVE-2016-6415 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “Cisco IOS, IOS XR, and IOS XE IKEv1 Information Disclosure 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.
Public exploit availability: although a public exploit is not directly linked in this CVE’s primary references, its place on the CISA KEV catalog confirms working attack code is in active use in the wild. treat weaponization as certain and patch on an emergency timeline.
Authoritative references:
Patch immediately. CISA's Known Exploited Vulnerabilities catalog lists this CVE, which means active exploitation has been confirmed. CISA KEV entry added 2023-05-19, federal due date 2023-06-09.
What is CVE-2016-6415?
CVE-2016-6415 is an information-disclosure flaw (CWE-200, Exposure of Sensitive Information to an Unauthorized Actor) in the server-side IKEv1 implementation shipped in Cisco IOS, IOS XE, and IOS XR software, plus the older PIX firewall. It is the bug the security community knows as BENIGNCERTAIN, surfaced in the 2016 Shadow Brokers leak of Equation Group tooling and tracked internally by Cisco as bug IDs CSCvb29204 and CSCvb36055.
The defect lives in how the IKE (Internet Key Exchange) version 1 daemon handles the first packet of an IPsec Security Association (SA) negotiation. A remote, unauthenticated attacker can send a crafted IKEv1 SA negotiation request to a device that is configured to terminate IKEv1, and the device leaks fragments of its own process memory back in the response. This is purely a confidentiality breach: there is no code execution, no configuration change, and no crash. The CVSS 3.1 base score is 7.5 (High) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, high confidentiality impact, but integrity and availability are untouched. That asymmetry matters when you triage: nothing on the box gets corrupted, but secrets walk out the door.
What can leak is the dangerous part. Researchers demonstrated extraction of memory regions that, on real configurations, held the device's RSA private keys, configured pre-shared keys, and other VPN credential material. With those in hand an attacker can decrypt captured IPsec/VPN traffic or impersonate the device, which is why this old 2016 bug landed on CISA's actively-exploited list years later.
Affected products and configurations
Per the Cisco advisory and the MITRE record, the affected software is:
- Cisco IOS 12.2 through 12.4 and 15.0 through 15.6
- Cisco IOS XE releases through 3.18S
- Cisco IOS XR 4.3.x and 5.0.x through 5.2.x (note: 5.3.0 and later were not listed as affected)
- Cisco PIX firewalls before 7.0 (long end-of-life)
Crucially, version alone does not decide exposure. A device is only vulnerable if it is configured to terminate IKEv1: that is, it actually has IPsec VPNs, DMVPN, GETVPN, FlexVPN (IKEv1 mode), GDOI, or similar features enabled. A switch or router running an affected IOS train with no crypto/IKE configuration does not expose this flaw. Cisco IOS XR releases 5.3.0 and later, and ASA software, were confirmed not affected.
Why this CVE matters
CVE-2016-6415 sits on CISA's Known Exploited Vulnerabilities catalog, added 2023-05-19, which only happens after active exploitation is observed in the wild. CISA's own SSVC assessment marks exploitation as active and the attack as automatable, meaning scanners can hit thousands of IKEv1 endpoints with no per-target work. Because the leaked memory can contain RSA private keys and pre-shared keys, a successful read does not just expose one session; it can compromise the trust anchor of your entire VPN, allowing decryption of past and future tunnels. Treat any unpatched, IKEv1-terminating, internet-reachable device as a key-rotation event, not just a patch event.
Am I affected?
Work this in two steps on the Cisco device itself, from the CLI. First confirm the software train, then confirm whether IKEv1 is actually configured and listening.
! 1. Identify the platform and software release
show version | include (IOS|Cisco|Version|RELEASE)
! 2. Is IKEv1 even configured? (no output here usually means not exposed)
show running-config | include crypto (isakmp|map|gdoi|gkm)
! 3. On IOS / IOS XE: is the device actively running IKEv1 SAs or listening on UDP 500/4500?
show crypto isakmp sa
show crypto session
! IOS XR equivalent
show version
show running-config crypto ikev1
show crypto ikev1 sa
If show running-config | include crypto isakmp returns nothing and you have no IPsec/DMVPN/GETVPN configuration, the device is not exposed to this specific flaw even on an affected train. If IKEv1 is configured, move to the fix.
How to fix CVE-2016-6415
There is no single “fixed version” string for this CVE. Cisco did not publish a one-line patched release because the fix landed across many IOS, IOS XE, and IOS XR trains at different rebuild numbers. The authoritative way to find your fixed build is the Cisco IOS Software Checker or the “Fixed Software” section of the advisory linked below. feed it your exact running release and it returns the first fixed maintenance release for your train. Do not guess a version; use the checker.
Step-by-step upgrade on Cisco IOS / IOS XE
! 1. Record the current image and free flash
show version | include image
dir flash:
! 2. Copy the fixed image (named by the Cisco Software Checker) onto the device.
! Verify the MD5/SHA from the Cisco download page BEFORE booting it.
copy scp: flash:
verify /md5 flash:<fixed-image-name>.bin
! 3. Point the boot system at the new image
configure terminal
no boot system
boot system flash:<fixed-image-name>.bin
end
write memory
! 4. Reload during a maintenance window
reload
On IOS XR, use the package/SMU workflow Cisco names in the advisory for your release (install add / install activate / install commit) rather than a monolithic image swap. PIX is end-of-life and receives no fix, those units must be replaced with a supported ASA or Firepower platform.
Rotate VPN credentials after patching
Because this flaw can leak RSA private keys and pre-shared keys from memory, patching alone does not undo a prior compromise. On any device that was exposed, regenerate the keys the leak could have exposed:
! Regenerate the device RSA keypair used for IKE/PKI, then re-enroll certificates
configure terminal
crypto key zeroize rsa
crypto key generate rsa modulus 2048
end
! Re-enroll with your CA and rotate every IKEv1 pre-shared key on the device.
If you can't patch immediately
Patching is the only durable fix. If a maintenance window is not available yet, reduce who can reach the IKEv1 service. IKEv1 uses UDP 500 and, when NAT-traversal is in play, UDP 4500: not TCP 443. Restrict those ports to known VPN peers with an interface ACL:
! Permit IKE only from your known peer addresses, drop the rest.
ip access-list extended IKE-LOCKDOWN
permit udp host <PEER-1> any eq 500
permit udp host <PEER-1> any eq 4500
permit udp host <PEER-2> any eq 500
permit udp host <PEER-2> any eq 4500
deny udp any any eq 500
deny udp any any eq 4500
permit ip any any
!
interface <WAN-interface>
ip access-group IKE-LOCKDOWN in
Where the design allows it, migrating peers to IKEv2 and disabling IKEv1 termination removes the vulnerable code path entirely. An ACL narrows the blast radius; it does not remove the flaw, and it offers nothing against an attacker who can spoof or already sits inside a trusted peer range.
How to verify the fix worked
After reload, confirm the running release matches the fixed build the Cisco Software Checker named for your train:
show version | include (Version|RELEASE|image)
! Compare the release string against the 'Fixed Software' value from the Cisco checker.
Then run an authenticated scan with a current signature set (the device must be reachable with SNMP/SSH credentials so the scanner reads the exact version) and confirm CVE-2016-6415 no longer flags. For any device that was IKEv1-reachable from untrusted networks while unpatched, finish the job: rotate the RSA keypair and all pre-shared keys as shown above, re-enroll certificates, and review IKE/syslog history for unexpected SA negotiation attempts from unknown peers.
Frequently asked questions
What is BENIGNCERTAIN and how is it related to CVE-2016-6415?
BENIGNCERTAIN is the name of the exploit tool from the 2016 Shadow Brokers leak that targets this exact flaw. CVE-2016-6415 is the formal identifier Cisco assigned to the underlying IKEv1 memory-disclosure bug (internal bug IDs CSCvb29204 and CSCvb36055) after the leak revealed it.
What software version fixes CVE-2016-6415?
There is no single fixed version. Cisco rebuilt the fix across many IOS, IOS XE, and IOS XR trains at different maintenance releases. Enter your exact running release into the Cisco IOS Software Checker (or read the “Fixed Software” section of the advisory) to get the first fixed build for your specific train. PIX is end-of-life and gets no fix.
My device runs an affected IOS train but has no VPN configured. Am I vulnerable?
No. The flaw is only reachable when the device is configured to terminate IKEv1 (IPsec VPN, DMVPN, GETVPN/GDOI, or FlexVPN in IKEv1 mode). Run show running-config | include crypto isakmp, if it returns nothing, the IKEv1 service is not active and this CVE does not apply to that box.
Do I need to rotate keys after patching?
Yes, if the device was reachable from untrusted networks while unpatched. The leak can expose RSA private keys and pre-shared keys from memory, so patching alone does not undo a prior compromise. Zeroize and regenerate the RSA keypair, re-enroll certificates, and rotate every IKEv1 pre-shared key.
References
- Official vendor advisory: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160916-ikev1
- NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2016-6415
- CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- CISA KEV record: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2016-6415
- Additional reference: http://www.securitytracker.com/id/1036841
- Additional reference: http://www.securityfocus.com/bid/93003
- Additional reference: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2016-6415
This guide was assembled from the official vendor advisory, the NVD record, and the CISA KEV catalog entry on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.
Related fixes
Other defects in the same area that deserve attention during this patch cycle:
- How to Fix CVE-2026-20777: Heap buffer overflow in libbiosig
- How to Fix CVE-2026-2919: Security Vulnerability in Focus for iOS
- How to Fix CVE-2025-54488: libbiosig (Bundle Sibling)
- How to Fix CVE-2004-1464: Uncontrolled Resource Consumption in Ios
- How to Fix CVE-2023-20109: Command Injection in IOS
People also ask
What is BENIGNCERTAIN and how is it related to CVE-2016-6415?
BENIGNCERTAIN is the exploit tool from the 2016 Shadow Brokers leak that targets this exact flaw. CVE-2016-6415 is the identifier Cisco assigned to the underlying IKEv1 memory-disclosure bug (internal IDs CSCvb29204 and CSCvb36055) after the leak revealed it.
What software version fixes CVE-2016-6415?
There is no single fixed version. Cisco rebuilt the fix across many IOS, IOS XE, and IOS XR trains at different maintenance releases. Enter your exact running release into the Cisco IOS Software Checker to get the first fixed build for your train. PIX is end-of-life and gets no fix.
My device runs an affected IOS train but has no VPN configured. Am I vulnerable?
No. The flaw is only reachable when the device terminates IKEv1 (IPsec VPN, DMVPN, GETVPN/GDOI, or FlexVPN in IKEv1 mode). If show running-config | include crypto isakmp returns nothing, the IKEv1 service is not active and this CVE does not apply to that box.