CVE-2025-52951: Juniper Junos Auth Bypass Vulnerability

CVE-2025-52951 Overview

CVE-2025-52951 is a Protection Mechanism Failure vulnerability in the kernel filter processing of Juniper Networks Junos OS. The flaw allows an unauthenticated remote attacker to bypass firewall filters configured on device interfaces by sending crafted IPv6 traffic destined to the control plane. The Junos OS kernel does not support the payload-protocol match keyword, so any firewall filter term containing it silently accepts all packets regardless of other match criteria. This exposes the routing engine to traffic that operators intended to block. The issue affects only control-plane firewall filters; transit filtering is not impacted. This CVE is tracked under [CWE-693] and represents a more complete fix for the previously disclosed CVE-2024-21607 (JSA75748).

Critical Impact
Control-plane firewall filter terms using payload-protocol behave as an implicit accept for all IPv6 traffic, exposing the Junos routing engine to attacker-supplied packets that policy was designed to drop.

Affected Products

Juniper Junos OS all versions before 21.2R3-S9
Juniper Junos OS 21.4 before 21.4R3-S11, 22.2 before 22.2R3-S7, 22.4 before 22.4R3-S7
Juniper Junos OS 23.2 before 23.2R2-S4, 23.4 before 23.4R2-S5, 24.2 before 24.2R2-S1, 24.4 before 24.4R1-S2 and 24.4R2

Discovery Timeline

2025-07-11 - CVE-2025-52951 published to NVD by Juniper SIRT
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-52951

Vulnerability Analysis

Junos OS supports rich firewall filter syntax that can match on protocol fields, addresses, and payload attributes. Operators commonly deploy loopback filters (lo0) to protect the Routing Engine from unwanted control-plane traffic. Within these filters, the payload-protocol match keyword is intended to identify the upper-layer protocol carried inside IPv6 packets, including those with extension headers. The kernel filter compiler, however, does not implement this match. Instead of rejecting the configuration or logging an error, the kernel silently treats the term as if no match criteria were present and evaluates the action against every packet. When the action is accept, all traffic reaching that term is passed to the control plane, effectively neutralizing the surrounding policy.

Root Cause

The root cause is a Protection Mechanism Failure [CWE-693] in the Junos OS kernel filter processing path. The compiler accepts syntactically valid filter terms containing payload-protocol but fails to enforce the intended match semantics at runtime. Any additional criteria in the same term, such as source address, port, or ICMPv6 type, are also disregarded because the term short-circuits to accept.

Attack Vector

An unauthenticated attacker on any network path that can deliver IPv6 packets to an affected interface can reach the Routing Engine on protocols the operator believed were filtered. This includes management daemons, routing protocol listeners, and other control-plane services. Because the bypass is silent and configuration-driven, it persists across reboots until the operator either patches Junos OS or removes the offending filter terms. The vulnerability does not require authentication, user interaction, or knowledge of internal topology beyond an IPv6 address for the target interface.

Detection Methods for CVE-2025-52951

Indicators of Compromise

Unexpected inbound IPv6 flows to Routing Engine services such as SSH, NETCONF, BGP, or SNMP that should be blocked by a lo0 firewall filter.
Control-plane connections from source prefixes that are outside the prefix-list allowed by the intended filter policy.
Absence of discard or reject counter increments on filter terms that contain the payload-protocol match.

Detection Strategies

Audit all Junos configurations for firewall filter terms containing the payload-protocol match keyword using show configuration | display set | match payload-protocol.
Compare intended control-plane policy against observed traffic on the Routing Engine by inspecting show firewall filter <name> counters and correlating with monitor traffic interface lo0.
Ingest Junos syslog and flow telemetry into a centralized analytics platform and alert on control-plane connections that do not match approved management sources.

Monitoring Recommendations

Enable and forward Junos structured syslog for authentication, NETCONF, and RE-bound flow events to a SIEM or data lake for baseline analysis.
Deploy IPv6 flow monitoring (sampled or inline-jflow) toward the Routing Engine and alert on unexpected protocol distributions.
Track configuration drift with automated tooling so that filter terms referencing payload-protocol are surfaced during change review.

How to Mitigate CVE-2025-52951

Immediate Actions Required

Upgrade Junos OS to a fixed release: 21.2R3-S9, 21.4R3-S11, 22.2R3-S7, 22.4R3-S7, 23.2R2-S4, 23.4R2-S5, 24.2R2-S1, 24.4R1-S2, 24.4R2, or later.
Immediately review all lo0 and control-plane firewall filters for terms containing payload-protocol and refactor them to use supported match criteria such as next-header or protocol.
Restrict IPv6 reachability to management interfaces at upstream devices until the affected system is patched.

Patch Information

Juniper Networks published fixes in the security advisory JSA100055. The patched releases correct the kernel filter compiler so that unsupported match keywords do not cause implicit accept behavior, closing the gap left by the earlier CVE-2024-21607 remediation.

Workarounds

Replace payload-protocol with next-header in IPv6 firewall filter terms protecting the Routing Engine, which is supported by the kernel filter path.
Apply an explicit terminating discard term at the end of each control-plane filter so that traffic not matched by earlier terms is dropped rather than accepted by default.
Enforce IPv6 access control on adjacent devices or edge routers as compensating protection until Junos OS is upgraded.

bash

# Configuration example: replace payload-protocol with next-header on lo0 filter
set firewall family inet6 filter protect-re term allow-bgp from next-header tcp
set firewall family inet6 filter protect-re term allow-bgp from source-prefix-list bgp-peers-v6
set firewall family inet6 filter protect-re term allow-bgp from destination-port bgp
set firewall family inet6 filter protect-re term allow-bgp then accept
set firewall family inet6 filter protect-re term default-deny then count v6-re-denied
set firewall family inet6 filter protect-re term default-deny then discard
set interfaces lo0 unit 0 family inet6 filter input protect-re