HowToFixMe
● Medium · CVSS 6.5

How to Fix CVE-2026-0203: Denial of Service in Junos OS

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

⚡ At a glance
SeverityCVSS 6.5 - Medium
Actively exploited?Not currently listed in CISA KEV
Affected0 < 21.2R3-S9, 21.4 < 21.4R3-S10, 22.2 < 22.2R3-S7, 22.3 < 22.3R3-S4, 22.4 < 22.4R3-S5, 23.2 < 23.2R2-S3, and others
Fixed inJunos OS 21.2R3-S9, 21.4R3-S10, 22.2R3-S7, 22.3R3-S4, 22.4R3-S5, 23.2R2-S3, 23.4R2-S3, 24.2R1-S2, 24.2R2, 24.4R1 (also 20.2R3-S10) and later
Type (CWE)CWE-755: Improper Handling of Exceptional Conditions

Exploitation status

CVE-2026-0203 is not currently on the CISA Known Exploited Vulnerabilities (KEV) catalog, so there is no U.S.-government-confirmed in-the-wild exploitation on record for it. Absence from KEV is not reassurance: the catalog frequently lags live exploitation, so treat the patch on its normal severity timeline.

Public exploit availability: there is no public exploit or Metasploit module in the listed references at present. Absence of a published exploit does not mean none exists privately, so keep the risk rating realistic.

What is CVE-2026-0203?

CVE-2026-0203 is a denial-of-service flaw in Juniper Networks Junos OS, tracked by Juniper as advisory JSA104294 and classified as CWE-755 (Improper Handling of Exceptional Conditions). The packet-processing path on the Flexible PIC Concentrator (FPC) mishandles a specific kind of malformed input: when an ICMP packet arrives carrying a specifically malformed IP header value, the FPC receiving that packet crashes and restarts. While the FPC reboots, every interface it hosts goes dark, so the impact lands squarely on availability with no confidentiality or integrity exposure.

Three details from the advisory sharply narrow the blast radius, and they matter when you triage this:

The vulnerability is unauthenticated and needs no privileges or user interaction. The CVSS v3.1 base score is 6.5 (Medium) with vector AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; Juniper also scores it 7.1 (High) under CVSS v4.0, with availability as the only impacted property.

Why this CVE matters

This is not a remote code execution bug and it does not corrupt memory in an exploitable way. It is a clean availability hit: one malformed ICMPv4 packet, and the FPC that received it crashes and restarts. On a router that means every port on that line card drops, sessions reset, and any traffic transiting that FPC stalls until the card comes back up. For an edge or core box carrying customer or branch traffic, a few seconds of FPC downtime is a measurable outage.

The constraints cut both ways. Because the attacker has to be network-adjacent and the malformed packet will not survive a forwarding hop, this is not something a botnet on the open internet can spray at you. The realistic threat model is an attacker who already has a foothold on a directly connected segment, a compromised CPE or peer, or a misbehaving device on a shared L2 domain. That keeps the urgency at Medium rather than emergency, but it does not make it ignorable: a single adjacent host can repeatedly crash an FPC and hold a link down. Juniper SIRT reports no known malicious exploitation, and there is no public proof-of-concept on record, so you can schedule this on a normal severity-driven patch cycle rather than treating it as a fire drill.

Am I affected?

You are affected if your installation matches any of these version ranges:

Check your installed version against the list above. If you cannot determine the version, treat the system as affected and follow the upgrade path below. Remember the AFT exception: if the box only runs AFT-based line cards (MPC10, MPC11, LC4800, LC9600, MX304), it is not affected regardless of Junos release.

From the Junos CLI, run show version to print the running release and the model. The release string is what you compare against the affected ranges. On a chassis with multiple FPCs, show chassis fpc tells you which line cards are installed so you can confirm whether any non-AFT FPC is present in the forwarding path.

How to fix CVE-2026-0203

There are no known workarounds for this issue, per Juniper's advisory. The only durable remediation is to upgrade Junos OS to a fixed release. Juniper has published fixed builds across every supported train:

The upgrade workflow on Junos:

  1. Read the vendor advisory in full: https://supportportal.juniper.net/JSA104294, then pick the fixed release that matches your current train from the list above.
  2. Download the signed Junos image for your platform from the Juniper Support download portal. Match the image to the exact chassis and Routing Engine you run.
  3. Save your configuration and a rescue config first: request system configuration rescue save, and copy the running config off-box.
  4. Schedule a maintenance window. The FPC restart behaviour means an in-place Junos upgrade is a disruptive event; on a chassis cluster or dual-RE box, upgrade the backup Routing Engine first, switch over, then upgrade the former primary (ISSU/unified-ISSU only where your platform and release pair support it).
  5. Install the image and reboot into it, then confirm the running version (see verification below).

Upgrade Junos to the patched release

# Confirm the running Junos build and platform first
show version
show chassis fpc

# Stage and install the signed image for your fixed train, e.g. 22.4R3-S5.
# Replace the filename with the exact signed package you downloaded from Juniper.
request system software add /var/tmp/junos-install-mx-x86-64-22.4R3-S5.tgz reboot

# After the reboot completes, confirm the new release is running
show version

On dual-RE and chassis-cluster platforms, prefer the documented graceful-Routing-Engine-switchover or in-service-software-upgrade procedure in the JSA104294 advisory and your platform's install guide rather than a flat add ... reboot, so you do not drop the whole chassis at once.

If you cannot patch immediately

Juniper states there are no known workarounds. Because the trigger is a malformed ICMPv4 packet from an adjacent network, the only meaningful interim hardening is to tighten what can reach the FPC at the IP layer. On the affected segments, restrict or filter inbound ICMPv4 from untrusted adjacent hosts with a firewall filter / loopback (lo0) input filter, and lock down which devices share the L2 domain with the router's interfaces. These are partial mitigations only: they shrink the set of hosts that can send the packet, but they do not remove the underlying crash condition. Upgrade as soon as a maintenance window allows.

How to verify the fix worked

If an adjacent host had been crashing an FPC before you patched, look back through show log messages and the core-dump records for the window in question. Repeated FPC restarts clustered around traffic from one adjacent source are the signature of this issue being triggered, accidentally or deliberately, on your network.

Frequently asked questions

Is CVE-2026-0203 being exploited in the wild?

No. Juniper SIRT states it is not aware of any malicious exploitation, the CVE is not on the CISA KEV catalog, and CISA's SSVC assessment records exploitation status as "none". There is no public proof-of-concept linked in the advisory. Patch on a normal severity-based schedule rather than as an emergency.

Does this affect ICMPv6 or only ICMPv4?

Only ICMPv4. Juniper explicitly states ICMPv6 is not vulnerable to this issue. The malformed value lives in the IPv4 header path.

My MX runs MPC10 / MPC11 / MX304 line cards. Am I affected?

No. Juniper clarified that AFT-based line cards (MPC10, MPC11, LC4800, LC9600, and MX304) are not affected by this issue. If your entire forwarding plane is AFT-based, you do not need to act for this CVE, though you should still track your overall Junos patch level.

Can an attacker on the public internet hit this remotely?

Not directly. The attack vector is network-adjacent (CVSS AV:A). Because of the specific malformation, upstream routers will not forward the offending packet, so the practical attack surface is limited to directly adjacent networks. The realistic threat is a compromised or hostile device on a connected segment, not a remote internet scanner.

Is there a workaround if I cannot patch right now?

Juniper lists no known workarounds. The only durable fix is upgrading to a fixed Junos release. As interim hardening you can restrict inbound ICMPv4 from untrusted adjacent hosts with a firewall filter, but that only narrows exposure rather than removing the crash condition.

References

This guide was assembled from Juniper advisory JSA104294, the CVE record (CVE-2026-0203), the NVD entry, and CISA's SSVC vulnrichment data. CVE-2026-0203 is not listed on the CISA KEV catalog. Always confirm against the vendor advisory before applying changes in production.

Mechanism and blast radius

The root cause is an improper handling of an exceptional condition (CWE-755) in the FPC's packet-processing code. A well-formed ICMPv4 packet is parsed and either processed or dropped without incident. This bug surfaces when the IP header carries a specific malformed value that the code path does not anticipate. Instead of discarding the bad packet gracefully, the FPC hits an unhandled exceptional state and crashes, then restarts. There is no memory disclosure and no code execution; the only consequence is that the line card cycles, which is why the impact metrics show availability High and confidentiality and integrity None.

Two design facts in the advisory bound how far this can reach. First, the malformation is in the IPv4 header, so the vulnerable path is ICMPv4-specific and an IPv6-only ICMP flow cannot trigger it. Second, the same malformation that crashes the FPC also prevents upstream routers from forwarding the packet at all. That self-limiting property is why Juniper classifies the attacker as network-adjacent rather than remote: the packet has to be injected on a network directly adjacent to the target interface, because it will not survive a routed hop. In practice that means the threat actor needs L2 adjacency or control of a directly connected device, peer, or CPE.

The blast radius on a single chassis depends on which FPC receives the packet. Only the receiving FPC crashes and restarts; other FPCs in the same chassis keep forwarding. But for the duration of the restart, every physical interface hosted on that card is down, so all the links, subscribers, peers, or branch circuits homed on that FPC experience an outage. On a busy edge router that is a real, customer-visible event, and a determined adjacent attacker can replay the packet to hold the card in a restart cycle.

Hunting for prior triggering

Because there is no confirmed exploitation and no public exploit, you are not hunting for a known attacker toolkit. You are looking for evidence that an FPC crashed and restarted in a pattern that does not match a planned reboot or a hardware fault. The signals to pull on a potentially affected Junos device:

If you find no recurring FPC restarts and no core dumps tied to adjacent traffic, the most likely conclusion is that the issue was never triggered on your box. Patch, confirm the running version, and move on. Keep the device's syslog forwarding intact so that any future FPC crash is captured off-box where an attacker on the line card cannot scrub it.

Other flaws in this area worth reviewing while you patch this one:

People also ask

Is CVE-2026-0203 being exploited in the wild?

No. Juniper SIRT is not aware of any malicious exploitation, the CVE is not on the CISA KEV catalog, and CISA's SSVC assessment records exploitation as "none". There is no public proof-of-concept. Patch on a normal severity-based schedule.

Does this affect ICMPv6 or only ICMPv4?

Only ICMPv4. Juniper explicitly states ICMPv6 is not vulnerable. The malformed value is in the IPv4 header path.

My MX runs MPC10 / MPC11 / MX304 line cards. Am I affected?

No. AFT-based line cards (MPC10, MPC11, LC4800, LC9600, and MX304) are not affected. If your forwarding plane is entirely AFT-based, this CVE does not require action.

Can an attacker on the public internet hit this remotely?

Not directly. The attack vector is network-adjacent (AV:A). The malformed packet will not be forwarded by upstream routers, so the practical attack surface is limited to directly adjacent networks.

Is there a workaround if I cannot patch right now?

Juniper lists no known workarounds. Upgrading to a fixed Junos release is the only durable fix. Restricting inbound ICMPv4 from untrusted adjacent hosts with a firewall filter narrows exposure but does not remove the crash condition.