Junos rpd: out-of-bounds write in EVPN route processing when the l2vpn-evpn RIB telemetry sensor is subscribed

CVSS 8.7CVE-2026-102179Firmware, BMC & network fabriccurated

Impact

An EVPN peer can crash rpd on a Junos leaf or spine, which drops BGP, EVPN and every other routing adjacency on that box until the daemon restarts and reconverges. On an EVPN-VXLAN GPU fabric this is the control plane for tenant overlays: while rpd is down, VTEP and MAC/IP route state goes stale, so east-west traffic between GPU nodes and to storage can black-hole across the affected switch. The precondition is specific - the l2vpn-evpn RIB streaming telemetry sensor must be subscribed, which is exactly the configuration a monitored datacenter fabric runs. Repeated route sends can keep rpd in a crash loop, so the outage is not necessarily self-limiting.

Who can reach it

A configured BGP EVPN peer - no additional authentication beyond being an established peer, so this is reachable from any device that already holds an EVPN session (another fabric switch, or a peer on a cross-tenant or partner-facing link).

What to do

Upgrade to a Junos OS / Junos OS Evolved release listed in JSA112187; a Junos upgrade means a routing-engine reload, so plan it per switch (graceful on a dual-RE chassis, a device reboot on single-RE leaves - and traffic loss on any node whose uplinks are not dual-homed). As an interim step the record points at the telemetry subscription as the trigger: removing the l2vpn-evpn RIB sensor subscription takes away the path without an upgrade. The advisory is the authority on fixed versions; this record does not list them.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-102179 https://supportportal.juniper.net/JSA112187

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.