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 gives an unauthenticated attacker a straightforward way to knock out VPN connectivity entirely through repeated exploitation.
Juniper Networks is one of the largest networking equipment vendors globally, and held the second-largest market share for firewall products, at 24.8 percent, before its acquisition by Hewlett Packard Enterprise. The SRX Series is Juniper's primary security appliance line, widely deployed in data centers and branch offices. The MX Series is a high-performance routing platform often used for managed VPN services. A way to deny VPN service on these platforms reaches across both 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 is in the IPsec library used 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 negotiate IKE/IPsec security associations on SRX Series and MX Series devices.
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 library's parsing logic hits an unexpected structure and the kmd or iked process crashes. Juniper tracks the internal bug as Problem Report PR1909025.
Attack Flow
The exploitation path is simple:
-
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).
-
The attacker constructs a malformed ISAKMP packet that deviates from the expected syntactic structure. The packet is built to be the first message in an IKE negotiation (the initiator's first exchange packet).
-
The attacker sends this single malformed packet to the target device. No authentication, credentials, or prior session state is required, and the attack complexity is low.
-
On receiving the packet, the
kmdorikedprocess crashes and begins a restart sequence. During the restart window, the device cannot process new VPN connection requests or establish new security associations. -
Existing established tunnels might not be torn down by the crash itself, but any event that requires a rekey or a new tunnel will fail. By sending malformed packets continuously, the attacker traps the daemon in a perpetual crash loop, and the device cannot establish any new VPN connections.
Severity Scoring
The CVSS scores reflect how easy the flaw is to exploit and how severe the availability impact is:
| 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 a network attack vector, low complexity, and no required privileges together make it a serious operational threat.
Patch Information
Juniper Networks fixed CVE-2026-33778 in a firmware-level update released as part of its 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 rejected before they can reach the crash path in kmd/iked.
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 before 22.4R3-S9 are considered vulnerable, so the bug spans the entire legacy release spectrum. There are no workarounds. Upgrading to one of the fixed releases above is the only remediation. Administrators should pick the fixed release for their current deployment train to minimize compatibility risk during the upgrade.
Tenable has published Nessus plugin 305590 (juniper_jsa107868.nasl) for automated detection of unpatched devices.
Detection Methods
Automated Scanning
The main publicly available detection method is Tenable's Nessus plugin (ID 305590), published on April 8, 2026. The plugin runs a version-based check against the Junos OS on the target device. It belongs to the "Junos Local Security Checks" family and needs 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, the most straightforward way to find exposure is to update your plugin feed and run a credentialed scan against your SRX Series and MX Series devices.
Manual Version Auditing
For manual checks, the Juniper advisory defines the affected version ranges clearly. Check your running Junos version with the standard show version CLI command and compare it against the fixed versions in the Patch Information section above. Treat any Junos OS installation on SRX or MX Series devices running a version below the fixed releases as vulnerable.
Behavioral and Operational Monitoring
The most telling sign of active exploitation is unexpected, repeated crashes and restarts of the kmd or iked processes on SRX and MX devices. Operators should watch system logs for core dump events or daemon restart entries tied to kmd or iked. Repeated occurrences, especially when they line up with failed VPN session establishment, are a strong signal that the vulnerability may be under active exploitation.
Network Layer Monitoring
The attack uses a malformed ISAKMP packet sent as the first message in an IKE negotiation, so network-level monitoring should focus on traffic to UDP port 500 (standard ISAKMP/IKE) and UDP port 4500 (NAT Traversal). No Snort, Suricata, or other IDS/IPS signatures for this CVE have been published as of this writing. Security teams can still look for anomalous patterns on these ports, such as a high volume of incomplete IKE negotiations from a single source, or repeated IKE initiation packets that never get past the first exchange. These patterns, together with daemon crash evidence on the device itself, would strongly suggest exploitation attempts.
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. That 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. These version ranges are vulnerable:
- All versions before 22.4R3-S9 (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
25.4R1 and all subsequent releases are not affected.
The vulnerable configuration requires IPsec VPN services to be active on the device, with the kmd or iked daemon listening for IKE negotiations on UDP port 500 or UDP port 4500.
Vendor Security History
In December 2015, Juniper disclosed that unauthorized code had been found in the ScreenOS software that powers its NetScreen firewalls. The incident involved two critical issues: an administrative backdoor (CVE-2015-7755) allowing unauthorized remote access, and a separate vulnerability that allowed decryption of VPN traffic (CVE-2015-7756). ScreenOS showed 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. That targeting is a reason to patch Juniper devices promptly, particularly those serving as VPN gateways and network perimeter security appliances.
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, though, which indicates 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)



