CVE-2025-52983: Juniper Junos Auth Bypass Vulnerability

CVE-2025-52983 Overview

CVE-2025-52983 is a UI Discrepancy for Security Feature vulnerability [CWE-446] affecting Juniper Networks Junos OS on VM Host systems. The flaw resides in the user interface used to manage SSH public keys on VM Host Routing Engines (RE). When an administrator removes the configured public key for the root account, the system continues to accept logins from holders of the corresponding private key. A network-based attacker who retains the matching private key can authenticate as root and gain administrative access to the device.

Critical Impact
Removed root SSH public keys remain active on VM Host Routing Engines, allowing prior key holders to authenticate as root over the network despite the configuration showing the key was deleted.

Affected Products

Juniper Junos OS all versions before 22.2R3-S7
Juniper Junos OS 22.4 versions before 22.4R3-S5, 23.2 versions before 23.2R2-S3
Juniper Junos OS 23.4 versions before 23.4R2-S3, 24.2 versions before 24.2R1-S2 and 24.2R2

Discovery Timeline

2025-07-11 - CVE-2025-52983 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-52983

Vulnerability Analysis

The vulnerability stems from a disconnect between the Junos OS configuration interface and the underlying VM Host authentication subsystem. Administrators rely on the CLI to manage SSH authorized keys for privileged accounts. Removing the root public key through the UI should immediately revoke remote SSH access for any holder of the matching private key. On VM Host Routing Engines, the removal does not propagate to the authentication backend that actually validates SSH key material. The stale key remains trusted, and attackers in possession of the private key continue to log in as root. This grants full administrative control of the routing engine, including the ability to alter routing policy, exfiltrate configuration, and pivot deeper into the network.

Root Cause

The issue is classified as a UI Discrepancy for Security Feature flaw [CWE-446]. The Junos OS management interface reports a security action — removal of an SSH key — that the underlying VM Host platform does not enforce. Operators rely on the displayed configuration state and assume the credential has been revoked, while the authentication layer continues to honor the deleted material.

Attack Vector

Exploitation requires the attacker to possess the private key that previously matched a now-removed root SSH public key on the affected VM Host Routing Engine. With network reachability to the device's SSH service, the attacker initiates a standard public-key SSH session against root. Because the key was never effectively revoked, authentication succeeds and the attacker obtains a root shell on the RE. The attack does not require additional credentials, user interaction, or local access.

No public proof-of-concept code has been released. Refer to the Juniper Security Advisory JSA100089 for vendor technical details.

Detection Methods for CVE-2025-52983

Indicators of Compromise

Successful SSH logins to root on a VM Host Routing Engine after the configuration shows the corresponding public key was removed.
Authentication events for root originating from source addresses that do not match the documented administrative jump hosts.
Configuration changes, commit events, or shell command history on the RE that cannot be tied to an active authorized administrator session.

Detection Strategies

Reconcile the running SSH authorized key list on each VM Host RE against the committed Junos configuration to identify stale or orphaned keys.
Forward Junos messages and interactive-commands syslog streams to a centralized SIEM and alert on root SSH logins, especially via public-key authentication.
Audit recent delete system root-authentication ssh-* and equivalent configuration deletions, then verify that the keys are no longer active at the OS level.

Monitoring Recommendations

Continuously baseline administrative access to routing engines and alert on any authentication as root outside approved change windows.
Track SSH key fingerprints used during successful logins and flag fingerprints that are no longer present in the device configuration.
Monitor outbound connections, configuration commits, and file transfers initiated from RE shells for signs of post-compromise activity.

How to Mitigate CVE-2025-52983

Immediate Actions Required

Upgrade affected devices to a fixed Junos OS release: 22.2R3-S7, 22.4R3-S5, 23.2R2-S3, 23.4R2-S3, 24.2R1-S2, 24.2R2, or later.
Rotate any SSH key pair that has ever been authorized for root on a VM Host Routing Engine, treating previously removed keys as still trusted until the device is patched.
Restrict SSH management access to the routing engine to dedicated management networks and trusted bastion hosts only.

Patch Information

Juniper Networks has released fixed software addressing CVE-2025-52983. Apply the appropriate fixed release for the deployed train as documented in the Juniper Security Advisory JSA100089. Background on the affected architecture is available in the Juniper VM Host Overview Documentation.

Workarounds

Disable remote root login by setting system root-authentication to require local console access and removing SSH access for the root account.
Apply firewall filters and management plane access lists that restrict TCP/22 on the RE to a small set of trusted administrative source addresses.
Where supported, replace static SSH key authentication with a centrally managed TACACS+ or RADIUS account so revocation is enforced by the AAA server.

bash

# Configuration example: restrict SSH to management prefixes and disable root SSH login
set system services ssh root-login deny
set system services ssh connection-limit 10
set firewall family inet filter PROTECT-RE term ALLOW-MGMT-SSH from source-address 192.0.2.0/24
set firewall family inet filter PROTECT-RE term ALLOW-MGMT-SSH from protocol tcp
set firewall family inet filter PROTECT-RE term ALLOW-MGMT-SSH from destination-port 22
set firewall family inet filter PROTECT-RE term ALLOW-MGMT-SSH then accept
set firewall family inet filter PROTECT-RE term DENY-SSH from protocol tcp destination-port 22
set firewall family inet filter PROTECT-RE term DENY-SSH then discard
set interfaces lo0 unit 0 family inet filter input PROTECT-RE