CVE-2026-102080 in Junos OS
Summary
by MITRE • 10/14/2026
An Improper Resource Locking vulnerability in the clock synchronization daemon (clksyncd) of Juniper Networks Junos OS on MX Series allows a unauthenticated, logically adjacent attacker to cause a Denial-of-Service (DoS).
If a SyncE or PTP upstream node sends a malformed message to an MX device equipped with SCBE3, a false 19.44MHz alarm is generated on the master RE. This leads to persistent RE switchovers and a clksyncd process crash. This issue is outside the attacker's direct control as it's a race condition.
This issue affects Junos OS on MX Series:
* All versions before 23.2R2-S7.7; * 23.4 versions before 23.4R2-S8.13; * 24.2 versions before 24.2R2-S5.5; * 24.4 versions before 24.4R2-S4; * 25.2 versions before 25.2R2-S1; * 25.4 versions before 25.4R1-S2.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified as an Improper Resource Locking flaw within the clock synchronization daemon, known as clksyncd, in Juniper Networks Junos OS for MX Series routers represents a significant operational risk to network infrastructure stability. This specific defect allows an unauthenticated attacker who is logically adjacent to the target device to trigger a Denial-of-Service condition. The attack vector relies on the transmission of malformed messages from upstream nodes utilizing Synchronous Ethernet or Precision Time Protocol architectures. When such a node sends these improperly formatted packets to an MX Series router equipped with SCBE3 hardware, it initiates a sequence of events that disrupts the critical time-synchronization functions essential for modern telecommunications and data center operations.
The technical mechanism behind this vulnerability centers on a race condition within the clksyncd process. Upon receiving the malformed SyncE or PTP message, the system incorrectly generates a false alarm indicating a 19.44MHz frequency deviation on the master Routing Engine. This erroneous alert is not merely informational but triggers automated recovery mechanisms designed to handle hardware faults. Consequently, this leads to persistent switchovers of the Routing Engines as the system attempts to recover from what it perceives as a critical hardware failure. The continuous cycling between active and standby routing engines places extreme stress on the device's control plane resources.
The operational impact of this vulnerability is severe, resulting in both service disruption and potential data loss due to instability. The persistent RE switchovers cause intermittent connectivity issues for traffic passing through the router, effectively creating a Denial-of-Service scenario even though no actual malicious payload is delivered beyond the malformed synchronization packet. Furthermore, the race condition inherent in the flaw can lead to the complete crash of the clksyncd process itself. Since clock synchronization is foundational for many network protocols and logging mechanisms, its failure can degrade overall network performance, cause timestamp inaccuracies in security logs, and potentially impact other services that rely on precise timing information provided by this daemon.
From a classification perspective, this vulnerability aligns with CWE-362, which describes Concurrent Execution using Shared Resource with Improper Synchronization, commonly referred to as race conditions. The exploitation of this flaw allows an attacker to disrupt service availability without authentication, mapping directly to the Denial-of-Service tactics found in the MITRE ATT&CK framework under techniques such as T1499 Endpoint Denial of Service or more broadly affecting network infrastructure reliability. The lack of required authentication for a logically adjacent actor highlights the importance of securing management planes and synchronization interfaces against unauthorized access, even from trusted internal networks where trust boundaries may be loosely defined.
Mitigation strategies primarily involve applying the vendor-recommended software updates to address the underlying race condition in clksyncd. Organizations running affected versions must upgrade Junos OS immediately according to the specified version thresholds: all versions before 23.2R2-S7.7, 23.4 versions before 23.4R2-S8.13, 24.2 versions before 24.2R2-S5.5, 24.4 versions before 24.4R2-S4, 25.2 versions before 25.2R2-S1, and 25.4 versions before 25.4R1-S2 are susceptible to this issue. In addition to patching, network architects should implement strict access control lists on SyncE and PTP interfaces to restrict communication only to known, trusted upstream nodes. This reduces the attack surface by ensuring that malformed packets from untrusted or compromised adjacent devices cannot reach the synchronization daemon. Regular monitoring of system logs for false frequency alarms can also serve as an early detection mechanism for potential exploitation attempts before a full crash occurs.