CVE-2026-37460: FRRouting (FRR) DoS Vulnerability

CVE-2026-37460 Overview

CVE-2026-37460 is a denial of service vulnerability in FRRouting (FRR), an open-source internet routing protocol suite used in production networks and network appliances. The flaw resides in the rfapiRibBi2Ri() function inside rfapi_rib.c, which handles RFAPI RIB (Routing Information Base) processing for the BGP daemon. Missing input validation allows a remote attacker to trigger a Denial of Service (DoS) by sending a crafted Border Gateway Protocol (BGP) UPDATE message to an affected peer. The issue affects FRRouting branches stable/10.0 through stable/10.6.

Critical Impact

A crafted BGP UPDATE message from a configured peer can crash the FRR BGP daemon, disrupting routing announcements and network reachability.

Affected Products

• FRRouting stable/10.0 through stable/10.6
• Network appliances and Linux distributions bundling vulnerable FRR releases
• BGP deployments using the RFAPI/VNC feature path

Discovery Timeline

• 2026-06-03 - CVE-2026-37460 published to NVD
• 2026-06-03 - Last updated in NVD database

Technical Details for CVE-2026-37460

Vulnerability Analysis

The vulnerability exists in the rfapiRibBi2Ri() routine within bgpd/rfapi/rfapi_rib.c. This function processes Backup Info (BI) entries and converts them into Route Information (RI) records used by the RFAPI RIB. The implementation lacks sufficient validation of fields parsed from incoming BGP UPDATE messages. When a crafted UPDATE traverses this path, the missing checks lead to an abnormal program state and termination of the BGP daemon.

Because BGP sessions are long-lived and the daemon is central to route propagation, a single crash forces session re-establishment and reconvergence. Repeated triggering keeps the daemon in a crash loop, producing a sustained outage on affected routers. The defect is corrected in the upstream commit referenced in GitHub Commit 7676cad6 and Pull Request #21098.

Root Cause

The root cause is improper input validation of fields parsed from a BGP UPDATE before they are dereferenced or used as control inputs in rfapiRibBi2Ri(). Without bounds and sanity checks on these inputs, attacker-controlled values reach code paths that assume well-formed data, causing the daemon to abort.

Attack Vector

Exploitation requires the ability to send BGP UPDATE messages to a vulnerable bgpd instance. In practice this means a configured BGP peer, a compromised peer router, or any party able to inject into a BGP session. The attacker sends a crafted UPDATE that exercises the RFAPI code path, after which bgpd terminates. No authentication beyond the existing BGP peering relationship is required, and no user interaction is needed.

No verified public exploit code is available. Technical details are described in the upstream patch referenced in FRRouting on GitHub.

Detection Methods for CVE-2026-37460

Indicators of Compromise

• Unexpected termination or repeated restarts of the bgpd process on FRR routers.
• BGP session flaps with peers immediately following receipt of UPDATE messages.
• Core dumps or crash logs referencing rfapiRibBi2Ri or rfapi_rib.c.
• Sudden withdrawal and reannouncement of large numbers of prefixes from an affected router.

Detection Strategies

• Monitor FRR bgpd exit codes and systemd restart events; treat unplanned restarts as suspicious.
• Inspect zebra.log and bgpd.log for stack traces, assertion failures, or RFAPI-related errors.
• Correlate BGP session resets with the source peer of the most recent UPDATE to identify the trigger.

Monitoring Recommendations

• Alert on changes in BGP neighbor state (Established to Idle/Active) across edge routers.
• Forward FRR logs and process telemetry to a central log platform for cross-router correlation.
• Track route table churn and session uptime as service-level indicators for routing stability.

How to Mitigate CVE-2026-37460

Immediate Actions Required

• Inventory all FRR deployments and identify systems running stable/10.0 through stable/10.6.
• Upgrade to a fixed FRR release that incorporates commit 7676cad6 or the changes in PR #21098.
• Restrict BGP peering to authenticated, trusted neighbors using TCP-AO or MD5 authentication and strict ACLs on TCP/179.
• Enable automatic restart of bgpd via systemd to reduce outage duration while patching is in progress.

Patch Information

The upstream fix is published in the FRRouting repository on GitHub. Apply the maintainer-provided patch from GitHub Commit 7676cad6 or rebuild from a branch containing Pull Request #21098. Distribution maintainers shipping FRR should be tracked for backported packages.

Workarounds

• Disable the RFAPI/VNC feature in bgpd if it is not required, removing the vulnerable code path from runtime use.
• Apply BGP inbound policies that drop or filter UPDATE attributes not expected from a given peer.
• Limit BGP sessions to known infrastructure peers and block TCP/179 from untrusted networks at the perimeter.

# Verify installed FRR version and disable RFAPI if not needed
vtysh -c 'show version'

# In /etc/frr/daemons, ensure RFAPI/VNC is not enabled unless required
# bgpd_options="   -A 127.0.0.1"   # default, no --enable-vnc flags at runtime

# Restart bgpd after upgrading to a patched build
systemctl restart frr
systemctl status frr --no-pager