Skip to main content
Vulnerability Database/CVE-2022-22153

CVE-2022-22153: Juniper Junos DOS Vulnerability

CVE-2022-22153 is a denial of service flaw in Juniper Junos OS affecting SRX and MX Series devices. Fragmented packets can cause severe latency and packet loss. This article covers technical details, affected versions, and mitigation.

Updated:

CVE-2022-22153 Overview

CVE-2022-22153 is a denial-of-service vulnerability in the flow processing daemon (flowd) of Juniper Networks Junos OS on SRX Series firewalls and MX Series routers equipped with the SPC3 services processing card. The flaw combines insufficient algorithmic complexity with allocation of resources without limits or throttling [CWE-407]. An unauthenticated remote attacker can introduce a high proportion of fragmented packets into transit traffic, forcing flowd to perform expensive reassembly operations. The result is increased packet processing latency and, in sustained conditions, packet loss across the affected device. Juniper published advisory JSA11261 to address this issue.

Critical Impact

Sending transit traffic where more than 5% of packets require IP reassembly causes high latency and packet drops on SRX and MX SPC3 platforms, degrading availability of network and security services.

Affected Products

  • Juniper Junos OS on SRX Series: all versions prior to 18.2R3, 18.3R3, 18.4R2-S9, 18.4R3, 19.1R2, 19.2R1-S1, 19.2R2
  • Juniper Junos OS on MX Series with SPC3 services card: same version ranges as SRX Series
  • Hardware platforms include SRX100/110/210/220/240/240h2/300/320/340/345/380/550/650, SRX1400/1500/3400/3600/4100/4200/4600, SRX5000/5400/5600/5800, and MX5/10/40/80/104/150/204/240/480/960, MX2008/2010/2020, MX10000/10003/10008/10016

Discovery Timeline

  • 2022-01-19 - CVE-2022-22153 published to NVD alongside Juniper advisory JSA11261
  • 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2022-22153

Vulnerability Analysis

The flowd daemon is the central forwarding component on SRX Series firewalls and on MX Series line cards equipped with SPC3. It performs session lookup, security policy evaluation, NAT, and stateful inspection on every transit packet. When fragmented IP packets arrive, flowd must hold fragments in memory, reorder them, and reconstruct the original datagram before applying security processing.

The affected versions implement reassembly using an algorithm whose computational cost grows non-linearly with the volume of fragments in flight. They also lack enforcement of an upper bound on resources allocated to the reassembly subsystem. An attacker who introduces a steady stream of fragments can drive CPU consumption and memory pressure on the services processing path beyond what legitimate forwarding can absorb.

Root Cause

The issue maps to [CWE-407] Inefficient Algorithmic Complexity. The reassembly logic in flowd does not cap the number of in-progress reassembly contexts or the work performed per fragment. Once fragmented traffic exceeds roughly 5% of the transit mix, the per-packet cost of reassembly grows enough to crowd out normal forwarding work on the same data plane.

Attack Vector

Exploitation requires only network access along a path that traverses an affected SRX or MX SPC3 device. No authentication, no privilege, and no user interaction are required. The attacker generates traffic destined to a reachable endpoint behind the device and ensures a sufficient fraction of packets are fragmented, for example by lowering the path MTU or by manually fragmenting at the source. The traffic does not need to terminate on the Junos device itself; transit packets are sufficient because reassembly occurs as part of normal flow processing.

No public proof-of-concept is associated with this CVE, and it is not listed in the CISA Known Exploited Vulnerabilities catalog. The vulnerability impacts availability only; confidentiality and integrity of traffic are not directly affected.

Detection Methods for CVE-2022-22153

Indicators of Compromise

  • Sustained elevation of flowd CPU utilization on SRX or MX SPC3 platforms not correlated with a legitimate traffic increase
  • A disproportionate share of IP fragments in transit traffic, particularly above the 5% threshold called out in Juniper advisory JSA11261
  • Rising counters for fragment reassembly, reassembly queue occupancy, or fragment drops on the affected device
  • Increased end-to-end latency or packet loss for flows traversing the affected security or services gateway

Detection Strategies

  • Baseline the normal ratio of fragmented to non-fragmented packets on each SRX/MX SPC3 device and alert on sustained deviations
  • Poll Junos SNMP and show security flow statistics style operational data to monitor flow session and reassembly metrics over time
  • Correlate firewall telemetry with upstream router NetFlow/IPFIX to identify sources generating abnormal fragment volumes

Monitoring Recommendations

  • Forward Junos syslog, flow logs, and SNMP traps to a centralized analytics platform for longitudinal analysis
  • Track flowd process CPU and memory pressure as a service-health metric, with thresholds tied to historical baselines
  • Alert on persistent packet drops attributed to the services processing path rather than to interface congestion

How to Mitigate CVE-2022-22153

Immediate Actions Required

  • Inventory all SRX Series firewalls and MX Series chassis using the SPC3 card and confirm Junos OS versions against the fixed releases listed in JSA11261
  • Schedule upgrades to a fixed Junos OS release on devices in the affected version ranges
  • Restrict who can source fragmented traffic toward affected devices, including filtering at upstream edge routers where feasible
  • Monitor fragment ratios on transit links and rate-limit anomalous sources at the network edge

Patch Information

Juniper Networks released fixed software in Junos OS 18.2R3, 18.3R3, 18.4R2-S9, 18.4R3, 19.1R2, 19.2R1-S1, 19.2R2, and all subsequent releases. Upgrade guidance and the complete list of resolved builds are documented in the Juniper Security Advisory JSA11261. No workaround fully eliminates the issue; patching is the recommended remediation.

Workarounds

  • Apply firewall filters or policers at the network edge to limit the volume of fragmented packets that can reach affected SRX or MX SPC3 devices
  • Where operationally acceptable, drop or rate-limit IPv4 and IPv6 fragments destined for or transiting the affected platform using stateless filters on ingress interfaces
  • Tune path MTU and TCP MSS clamping on upstream devices to reduce legitimate fragmentation and make malicious fragmentation easier to isolate
bash
# Example Junos stateless firewall filter to rate-limit IPv4 fragments on ingress
# Adapt interface names, policers, and counters to the local environment.
set firewall policer frag-policer if-exceeding bandwidth-limit 1m
set firewall policer frag-policer if-exceeding burst-size-limit 15k
set firewall policer frag-policer then discard

set firewall family inet filter LIMIT-FRAGS term rate-limit-frags from is-fragment
set firewall family inet filter LIMIT-FRAGS term rate-limit-frags then policer frag-policer
set firewall family inet filter LIMIT-FRAGS term rate-limit-frags then count frag-hits
set firewall family inet filter LIMIT-FRAGS term default then accept

set interfaces ge-0/0/0 unit 0 family inet filter input LIMIT-FRAGS

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.