CVE-2024-30407: Juniper JCNR Hard-coded Key Vulnerability

CVE-2024-30407 Overview

CVE-2024-30407 is a hardcoded cryptographic key vulnerability affecting Juniper Networks Juniper Cloud Native Router (JCNR) and the containerized Routing Protocol Daemon (cRPD). The container images ship with embedded SSH host keys that are identical across all deployments. An attacker positioned on the network path can use these keys to impersonate the SSH server and decrypt or modify administrative traffic without detection. Successful exploitation results in full compromise of the affected container. The flaw is tracked under CWE-321 (Use of Hard-coded Cryptographic Key).

Critical Impact
A Person-in-the-Middle attacker can intercept and tamper with SSH sessions to JCNR and cRPD containers, leading to complete container compromise and exposure of routing control-plane traffic.

Affected Products

Juniper Networks Juniper Cloud Native Router (JCNR) — all versions before 23.4
Juniper Networks containerized Routing Protocol Daemon (cRPD) — all versions before 23.4R1
Container deployments shipping default Juniper SSH host keys

Discovery Timeline

2024-04-12 - CVE-2024-30407 published to NVD
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2024-30407

Vulnerability Analysis

The vulnerability stems from SSH host keys being baked into the JCNR and cRPD container images at build time. Every container instance therefore presents the same private host key to clients connecting over SSH. SSH host keys exist to bind a server's identity to its public key fingerprint. When the private half is shared across all installations, that identity guarantee collapses.

An attacker who obtains the container image — which is distributed broadly to Juniper customers — can extract the private host key. With that key, the attacker can stand up a rogue SSH endpoint that produces an identical fingerprint to the legitimate container. Administrators and orchestration tooling relying on host-key pinning will not detect the substitution.

The impact is amplified because cRPD runs the Junos routing stack inside containers, often handling BGP, IS-IS, and OSPF control-plane sessions. Compromise of an administrative session can yield credentials, configuration data, and the ability to alter routing state.

Root Cause

The container build process generates or copies SSH host keys once and embeds them into the published image instead of generating fresh keys on first boot of each container instance. This violates the fundamental SSH trust model, which assumes each server holds a unique, secret private key.

Attack Vector

Exploitation requires network adjacency to intercept traffic between an SSH client and the targeted container. The attacker extracts the hardcoded private key from the public container image, then redirects SSH sessions through an attacker-controlled proxy that authenticates with the stolen key. No prior authentication on the target is required, and the attack is invisible to clients performing standard host-key verification. Refer to Juniper Security Advisory JSA79106 and Juniper Security Advisory JSA79107 for vendor technical detail.

Detection Methods for CVE-2024-30407

Indicators of Compromise

SSH host key fingerprints on JCNR or cRPD containers that match the default fingerprint shipped in the container image rather than a unique per-instance value.
Unexpected ARP, NDP, or routing changes on management network segments that could indicate traffic redirection toward a PitM proxy.
SSH sessions to cRPD or JCNR endpoints originating from or terminating on unexpected intermediate hosts.

Detection Strategies

Enumerate /etc/ssh/ssh_host_*_key.pub inside each running JCNR and cRPD container and compare fingerprints across the fleet; identical fingerprints across distinct instances confirm the defect.
Compare container host-key fingerprints against the values embedded in the Juniper-published image to identify unpatched deployments.
Inspect SSH client known_hosts files on jump hosts and automation servers for entries that reuse a single fingerprint across many cRPD or JCNR targets.

Monitoring Recommendations

Log and alert on SSH connections to cRPD and JCNR management interfaces from sources outside the approved administrative subnet.
Monitor the management network for layer-2 anomalies such as gratuitous ARP, duplicate MACs, or unexpected gateway changes that precede PitM attacks.
Track image versions in CI/CD and Kubernetes manifests, alerting when JCNR images earlier than 23.4 or cRPD images earlier than 23.4R1 are deployed.

How to Mitigate CVE-2024-30407

Immediate Actions Required

Upgrade JCNR to version 23.4 or later and cRPD to 23.4R1 or later, where Juniper regenerates SSH host keys per container instance.
Restrict SSH access to cRPD and JCNR management interfaces to a hardened jump host using network policy or NetworkPolicy objects in Kubernetes.
Rotate any administrative credentials, API tokens, or routing-protocol secrets that may have transited SSH sessions to vulnerable containers.

Patch Information

Juniper Networks resolves the issue in JCNR 23.4 and cRPD 23.4R1. Refer to Juniper Security Advisory JSA79106 for JCNR and Juniper Security Advisory JSA79107 for cRPD for fixed-release matrices and upgrade guidance. After upgrading, verify that each container instance presents a unique SSH host-key fingerprint.

Workarounds

Regenerate SSH host keys inside each running container by removing files under /etc/ssh/ssh_host_* and restarting sshd, then redistributing the new public-key fingerprints to administrators.
Place cRPD and JCNR SSH endpoints behind an SSH bastion that performs strict host-key pinning to the regenerated per-instance keys.
Disable password-based and key-based SSH access on cRPD and JCNR where operationally feasible, using out-of-band management instead until the upgrade is applied.

bash

# Regenerate SSH host keys inside an affected container
kubectl exec -it <jcnr-or-crpd-pod> -- /bin/sh -c '\
  rm -f /etc/ssh/ssh_host_*_key /etc/ssh/ssh_host_*_key.pub && \
  ssh-keygen -A && \
  kill -HUP $(pidof sshd)'

# Capture new fingerprints for known_hosts distribution
kubectl exec -it <jcnr-or-crpd-pod> -- \
  ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub