EUVD-2026-42712
GHSA-m4xf-x7w2-qgfq
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:Y/R:U/V:X/RE:M/U:X
AC:H reflects that rollover requires sustained high-volume failed negotiations; A:H reflects mandatory reboot to restore service, not limited degradation.
Primary rating from Vendor (juniper).
CVSS VectorVendor: juniper
Lifecycle Timeline
3DescriptionCVE.org
A Use of Multiple Resources with Duplicate Identifier vulnerability in the IKE daemon (iked) of Juniper Networks Junos OS on MX with SPC3 and SRX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS).
On an MX with SPC3 and SRX devices configured for VPN service, when a large number of VPN negotiations fail a peer index rollover will eventually occur. As a result, new peers are assigned index values that are already in use and the iked process starts to crash repeatedly. This results in failure to establish new VPN connections and rekeying existing ones. To restore service the system must be rebooted. Please note that the index value can't be monitored, so customers should monitor tunnel up and down events and if a lot of events occur over an extended period of time it becomes likely that this issue occurs.
To be exposed to this issue the system needs to run iked (vs. kmd which is not affected), which can be verified with:
user@host> show system processes extensive | match "KMD|IKED" This issue affects Junos OS on MX with SPC3, SRX Series:
- all versions before 23.2R2-S7,
- 23.4 versions before 23.4R2-S6,
- 24.2 versions before 24.2R2-S3,
- 24.4 versions before 24.4R2-S4,
- 25.2 versions before 25.2R1-S1.
AnalysisAI
Repeated IKE negotiation failures on Juniper Junos OS (MX with SPC3 and SRX Series) cause a peer index rollover that assigns duplicate index values to new peers, triggering continuous iked process crashes and a full VPN service outage requiring system reboot. Unauthenticated network-based attackers can deliberately flood the device with failing VPN negotiations to accelerate the rollover condition. No public exploit code or CISA KEV listing exists at time of analysis, but the network-reachable, zero-privilege attack vector makes this a meaningful risk for any organization relying on Juniper-based VPN infrastructure with iked enabled.
Technical ContextAI
The IKE daemon (iked) on Junos OS maintains a pool of peer index values to track VPN negotiation state. CWE-694 (Use of Multiple Resources with Duplicate Identifier) describes the root cause: when the peer index counter exhausts its range and rolls over, new peer entries are assigned indices already held by existing entries. This collision causes iked to enter a crash loop since it cannot resolve the ambiguous peer state. The vulnerability is specific to platforms running iked - not the legacy kmd daemon - which applies to MX series routers equipped with the SPC3 service processing card and SRX series firewalls. The affected CPE is cpe:2.3:a:juniper_networks:junos_os on these specific hardware configurations. The precondition (many failed negotiations) means the index space must be substantially consumed before rollover, but a sustained attacker-controlled flood of malformed or rejected IKE proposals can artificially accelerate this exhaustion.
RemediationAI
Upgrade to a fixed Junos OS release: 23.2R2-S7 or later, 23.4R2-S6 or later, 24.2R2-S3 or later, 24.4R2-S4 or later, or 25.2R1-S1 or later, per the Juniper advisory at https://supportportal.juniper.net/JSA110084. For systems that cannot be immediately patched, the most effective compensating control is to restrict IKE (UDP/500 and UDP/4500) access at the perimeter to known, trusted peer IP addresses only - this limits an external attacker's ability to generate the volume of failed negotiations needed to cause index rollover. Be aware that this workaround does not address cases where trusted peers can be spoofed or where the VPN gateway must accept connections from dynamic or unknown IPs. Operators should also implement monitoring for high-frequency tunnel up/down events as a leading indicator of approaching index exhaustion, since the index value itself cannot be observed directly. If the condition occurs before patching, a full system reboot is required to restore VPN service.
Denial-of-service in Juniper Networks Junos OS on MX Series (with SPC3) and SRX Series devices allows an unauthenticated
Remote denial of service in Juniper Networks Junos OS on MX Series (with SPC3) and SRX Series firewalls lets an unauthen
Privilege escalation in Juniper Networks Junos OS allows high-privileged local attackers to gain root access on Linux-ba
Denial-of-service in the Packet Forwarding Engine (PFE) of Juniper Junos OS on MX (with SPC3) and SRX-series firewalls l
Denial-of-service in Juniper Networks Junos OS on SRX Series devices lets an unauthenticated, network-based attacker exh
Denial-of-service in Juniper Networks Junos OS on EX Series switches (EX2300, EX3400, EX4000, EX4100, EX4400) lets a low
Denial-of-service in Juniper Junos OS on EX4100 and EX4400 Series switches allows an unauthenticated adjacent attacker t
Denial-of-service in Juniper Networks Junos OS on QFX10000 Series switches allows an unauthenticated, adjacent (Layer 2)
Denial-of-service in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS on MX Series routers lets an unauth
Out-of-bounds write in the Juniper Networks Junos OS http-gatekeeper (http-gk) process on SRX Series firewalls crashes t
Web filtering bypass on Juniper Networks Junos OS MX Series exposes downstream resources to unauthenticated network atta
Denial-of-service in Juniper Networks Junos OS and Junos OS Evolved on EX Series, QFX Series, and MX Series allows a loc
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today