Junos OS CVE-2026-102034

Exploitation requires the target Junos OS / Junos OS Evolved device to be explicitly configured for MC-LAG (multichassis link aggregation) with ICCP (Inter-Chassis Control Protocol) peering enabled - this is a non-default, feature-specific configuration. The attacker must additionally hold the network position of a configured ICCP peer (adjacent Layer 2 reachability on the ICCP link and acceptance as a trusted peer), reflected by the AV:A Adjacent vector. Limiting factors: devices without MC-LAG/ICCP configured are not affected; the adjacency and peer-trust requirement means arbitrary remote Internet attackers cannot reach the vulnerable code path; impact is confined to availability (daemon crash / DoS) with no confidentiality or integrity consequence.

This is a moderate-severity, availability-only denial-of-service issue (CWE-617 Reachable Assertion) that should be triaged as a real-but-conditional priority rather than an urgent emergency. The provided CVSS 4.0 vector (AV:A/AC:L/AT:N/PR:N/UI:N) with VA:H and all confidentiality/integrity impact set to N confirms the impact is restricted to availability of the l2ald daemon, with no code execution or data exposure. The AV:A (Adjacent) metric is the key risk limiter: the attacker must occupy the position of a configured ICCP peer, which is an adjacent, pre-trusted Layer 2 relationship, not an arbitrary remote Internet host - so despite PR:N, exploitation is not open to anonymous remote attackers. No EPSS score, KEV listing, or POC was supplied in the input; per precision rules there is no public exploit identified at time of analysis, and absence of these signals means exploitation probability cannot be quantified here. Note a tension worth flagging: the vector lists PR:N (no privileges) yet the description requires 'access to a configured ICCP peer,' meaning the practical barrier is network/trust positioning rather than account credentials - defenders should treat the ICCP peering relationship, not an authentication prompt, as the real gate. Overall: genuine for operators running MC-LAG, low urgency for those who do not.

An attacker who has compromised or can spoof a device participating in an MC-LAG ICCP peering relationship sends a malformed MC-LAG control message across the adjacent ICCP link. The l2ald daemon on the target Junos/Junos Evolved device hits a reachable assertion and crashes, disrupting Layer 2 forwarding and multichassis link aggregation. No public exploit code was identified in the provided data, and low attack complexity (AC:L) means a single crafted message suffices once the adjacent ICCP position is held.