Junos OS EUVD-2026-101444

Exploitation requires the device to be running a multichassis configuration that uses ICCP (Inter-Chassis Communication Protocol, e.g. MC-LAG), and the attacker must have adjacent access to an established ICCP peer session to inject malformed ICCP packets at the l2ald daemon. This is NOT a default-config, internet-facing flaw: the limiting factors are (1) ICCP must be configured and active, (2) the attacker must be logically adjacent on the inter-chassis control plane (AV:A), and (3) standalone routers without MC-LAG/ICCP are unaffected. No authentication is required per PR:N, but the adjacency and feature-enablement prerequisites substantially narrow the realistic attacker population.

This is a genuinely low-to-moderate priority issue, consistent with its 4.3 (Medium) CVSS score. The vector CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L indicates adjacent-network attack (AV:A), low complexity, and no privileges or user interaction, but the only rated impact is low availability (A:L) - notably, Juniper rated confidentiality as C:N even though the description explicitly cites 'memory disclosure,' which is a conflict defenders should note. No EPSS score, KEV listing, or public POC was provided, so there is no evidence of active or imminent exploitation; exploitation status is best characterized as no public exploit identified at time of analysis. The practical risk is sharply constrained by the AV:A vector combined with the requirement for access to an established ICCP peer session - an attacker must already be positioned on the inter-chassis control plane of a multichassis (MC-LAG) deployment, which is not a position most threat actors can casually reach. In short: real but niche, suited to normal patch-cycle remediation rather than emergency response.

An attacker who has gained a foothold on the inter-chassis control link of a Juniper MC-LAG pair (or can inject into an active ICCP peer session) sends malformed ICCP packets to a peer router. The improper input-quantity validation in the l2ald daemon causes it to disclose memory contents and crash, disrupting Layer 2 address learning on the device. No public exploit code is known at time of analysis, and exploitation requires adjacent positioning rather than remote internet access.