Introduction
A single malformed ISAKMP packet sent to a Juniper SRX or MX Series device can crash the key management daemon responsible for all VPN session negotiation, and there is no workaround available. For any organization relying on Juniper's SRX or MX platforms to terminate IPsec VPN tunnels, CVE-2026-33778 represents a straightforward, unauthenticated path to knocking out VPN connectivity entirely through repeated exploitation.
Juniper Networks is one of the largest networking equipment vendors globally, holding the second largest market share for firewall products at 24.8 percent prior to its acquisition by Hewlett Packard Enterprise. The SRX Series is Juniper's primary security appliance line, widely deployed in data centers and branch offices, while the MX Series serves as a high performance routing platform often used for managed VPN services. A vulnerability that can deny VPN service on these platforms has broad implications across enterprise and service provider networks.
Technical Information
Root Cause
The vulnerability is classified under CWE-1286: Improper Validation of Syntactic Correctness of Input. The flaw resides in the IPsec library consumed by two critical daemons on Junos OS: kmd (the key management daemon used in older configurations) and iked (the IKE daemon used in more modern deployments). These daemons are responsible for negotiating IKE/IPsec security associations on SRX Series and MX Series devices.
The core issue is that the IPsec library did not properly validate the structure of the very first ISAKMP (Internet Security Association and Key Management Protocol) packet received from a VPN initiator during IKE negotiation. When a specifically malformed initial ISAKMP packet arrives, the parsing logic in the library encounters an unexpected structure that leads to a crash of the kmd or iked process. The internal bug is tracked under Juniper Problem Report PR1909025.
Attack Flow
The exploitation path is remarkably simple:
-
Target identification. The attacker identifies a Juniper SRX or MX Series device with VPN services exposed on the network. The relevant listening ports are UDP 500 (standard ISAKMP/IKE) and UDP 4500 (NAT Traversal).
-
Crafting the malformed packet. The attacker constructs a malformed ISAKMP packet that deviates from the expected syntactic structure. This packet is designed to be the first message in an IKE negotiation (the initiator's first exchange packet).
-
Sending the packet. The attacker sends this single malformed packet to the target device. No authentication, credentials, or prior session state is required. The attack complexity is low.
-
Daemon crash. Upon receiving the malformed packet, the
kmdorikedprocess crashes and initiates a restart sequence. During this restart window, the device cannot process new VPN connection requests or establish new security associations. -
Sustained denial of service. While existing established tunnels might not be immediately torn down by the crash itself, any event requiring a rekey or new tunnel establishment will fail. By continuously transmitting malformed packets, the attacker traps the daemon in a perpetual crash loop, resulting in a complete inability to establish new VPN connections.
Severity Scoring
The CVSS scores reflect the ease of exploitation and the severity of the availability impact:
| Scoring Model | Base Score | Vector String |
|---|---|---|
| CVSS 3.1 | 7.5 (High) | AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
| CVSS 4.0 | 8.7 (High) | AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L |
Both scoring models confirm that confidentiality and integrity are unaffected. The vulnerability is purely an availability concern, but the combination of network attack vector, low complexity, and no required privileges makes it a serious operational threat.
Patch Information
Juniper Networks addressed CVE-2026-33778 through a firmware level fix released as part of their April 2026 quarterly security bulletin (advisory JSA107868, published April 8, 2026). The fix tightens input validation in the IPsec library so that syntactically malformed ISAKMP packets are correctly rejected before they can trigger the crash path in kmd/iked.
The following table lists the minimum fixed version for each supported release train:
| Release Train | Fixed Version |
|---|---|
| 22.4 | 22.4R3-S9 |
| 23.2 | 23.2R2-S6 |
| 23.4 | 23.4R2-S7 |
| 24.2 | 24.2R2-S4 |
| 24.4 | 24.4R2-S3 |
| 25.2 | 25.2R1-S2 or 25.2R2 |
| 25.4+ | 25.4R1 and all subsequent releases |
All Junos OS versions prior to 22.4R3-S9 are considered vulnerable, meaning the bug has existed across the entire legacy release spectrum. There are no workarounds available for this vulnerability. Upgrading to one of the fixed releases listed above is the only remediation path. Administrators should select the fixed release that corresponds to their current deployment train to minimize compatibility risks during the upgrade process.
Tenable has published Nessus plugin 305590 (juniper_jsa107868.nasl) to allow automated detection of unpatched devices.
Detection Methods
Automated Scanning
The primary publicly available detection method is Tenable's Nessus plugin (ID 305590), published on April 8, 2026. This plugin performs a version based check against the Junos OS running on the target device. It belongs to the "Junos Local Security Checks" family and requires the KB items Host/Juniper/model and Host/Juniper/JUNOS/Version to be present from a prior credentialed scan. If your organization uses Tenable Nessus or Tenable.io, updating your plugin feed and running a credentialed scan against your SRX Series and MX Series devices is the most straightforward way to identify exposure.
Manual Version Auditing
For teams performing manual checks, the affected version ranges are well defined in the Juniper advisory. You can check your running Junos version with the standard show version CLI command and compare it against the fixed version thresholds listed in the Patch Information section above. Any Junos OS installation on SRX or MX Series devices running versions prior to the fixed releases should be treated as vulnerable.
Behavioral and Operational Monitoring
The most telling indicator of active exploitation is unexpected, repeated crashes and restarts of the kmd or iked processes on SRX and MX devices. Operators should monitor system logs for core dump events or daemon restart entries associated with kmd or iked. Repeated occurrences, especially correlated with failed VPN session establishments, are a strong signal that the vulnerability may be under active exploitation.
Network Layer Monitoring
Since the attack vector involves a malformed ISAKMP packet sent as the first message in an IKE negotiation, network level monitoring should focus on traffic to UDP port 500 (standard ISAKMP/IKE) and UDP port 4500 (NAT Traversal). While no specific Snort, Suricata, or other IDS/IPS signatures for this CVE have been published as of this writing, security teams can look for anomalous patterns on these ports: a high volume of incomplete IKE negotiations from a single source, or repeated IKE initiation packets that never progress beyond the first exchange. These patterns, combined with daemon crash evidence on the device itself, would strongly suggest exploitation attempts.
It is worth noting that no YARA rules, Sigma rules, or traditional Indicators of Compromise such as file hashes, malicious IPs, or C2 domains have been published for this vulnerability. This is expected for a Denial of Service condition caused by improper input validation, which does not typically leave persistent forensic artifacts.
Affected Systems and Versions
The vulnerability affects Juniper Networks Junos OS running on SRX Series and MX Series devices with VPN services enabled. The following version ranges are vulnerable:
- All versions before 22.4R3-S9 (this encompasses the entire legacy release spectrum)
- 23.2 versions before 23.2R2-S6
- 23.4 versions before 23.4R2-S7
- 24.2 versions before 24.2R2-S4
- 24.4 versions before 24.4R2-S3
- 25.2 versions before 25.2R1-S2 and 25.2R2
Releases starting from 25.4R1 and all subsequent releases are not affected.
The vulnerable configuration requires the device to have IPsec VPN services active, with the kmd or iked daemon listening for IKE negotiations on UDP port 500 or UDP port 4500.
Vendor Security History
Juniper Networks has faced notable security incidents in the past that are relevant context for this vulnerability. In December 2015, Juniper disclosed that unauthorized code had been discovered in their ScreenOS software powering NetScreen firewalls. That incident involved two critical issues: an administrative backdoor (CVE-2015-7755) allowing unauthorized remote access, and a separate vulnerability permitting the decryption of VPN traffic (CVE-2015-7756). The ScreenOS incident demonstrated how quickly vulnerabilities in Juniper security appliances can escalate into severe compromises once they become public.
More recently, the ENISA 2025 Threat Landscape report noted that threat actors, including the group UNC3886, have specifically targeted Juniper routers and exploited zero day vulnerabilities in network infrastructure. This pattern of targeting underscores the importance of prompt patching for Juniper devices, particularly those serving as VPN gateways and network perimeter security appliances.
While Juniper SIRT has confirmed that no malicious exploitation of CVE-2026-33778 has been observed in the wild, the issue was discovered during production usage, indicating that real world traffic conditions can trigger the crash even without a deliberate attacker.
References
- Juniper KB: JSA107868
- Juniper Support Portal: 2026-04 Security Bulletin for CVE-2026-33778
- NVD: CVE-2026-33778
- CVE.org: CVE-2026-33778
- Tenable: CVE-2026-33778
- Tenable Nessus Plugin 305590
- Tenable Pipeline: JSA107868
- Feedly CVE Tracker: CVE-2026-33778
- ENISA Threat Landscape 2025
- Juniper Networks (Wikipedia)
- Rapid7: CVE-2015-7755 Juniper ScreenOS Authentication Backdoor
- Juniper: ScreenOS Multiple Security Issues (CVE-2015-7755, CVE-2015-7756)
