Junos OS CVE-2026-102175

The device must be configured for SDX/SRC service deployment so that the sdxd daemon is active and maintaining a service-deployment TCP connection to an SDX/SRC server - this is an optional feature, not a default configuration, which is the primary limiting factor. The attacker must additionally control or intercept that specific server connection (a machine-in-the-middle position on the SDX/SRC path, or a compromised/spoofed SDX/SRC server) in order to deliver the crafted frame; the daemon itself requires no authentication from that position (PR:N). Devices not running SDX/SRC are not exposed. These prerequisites meaningfully reduce the realistic attack surface below what the raw network/unauthenticated scoring suggests.

This is a genuinely high-severity issue but with an important real-world caveat that tempers the raw 9.3 score. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H) depicts an unauthenticated, network-reachable, low-complexity path to full compromise (code execution as root or DoS), and the supplemental metrics flag it as Automatable (AU:Y) - all of which argue for high priority. However, the description imposes a substantial precondition that the vector's AC:L/AT:N does not reflect: the attacker must 'control or intercept the configured SDX/SRC server connection,' i.e. occupy a machine-in-the-middle position or have compromised the trusted SDX/SRC server the daemon talks to. That is a materially harder starting position than generic internet-facing exploitation, so the effective complexity is higher than the vector states - a signal worth verifying with Juniper. On the mitigating side, no EPSS score, KEV listing, or public POC was provided, so there is no evidence of active or imminent exploitation. Exploitation status: no public exploit identified at time of analysis. Net: prioritize patching on devices that actually run SDX/SRC service deployment, but the MITM/trusted-server prerequisite means this is not a drop-everything internet-wormable bug for the typical Junos deployment where sdxd is not configured.

An attacker who has gained a man-in-the-middle position on the network path between a Junos device and its configured SDX/SRC server (or who has compromised that server) sends a crafted service-deployment frame over the TCP connection to the sdxd daemon. The malformed frame triggers a heap-based buffer overflow in sdxd, which runs as root, letting the attacker execute arbitrary code as root or crash the daemon for denial of service. No public exploit code is known at time of analysis; the attack hinges on first achieving control or interception of the SDX/SRC connection.