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

CVE-2026-37458 Overview

CVE-2026-37458 is an input validation vulnerability in the MP_REACH_NLRI attribute handler of FRRouting (FRR), an open-source internet routing protocol suite. The flaw affects FRR versions stable/10.0 through stable/10.6. An authenticated Border Gateway Protocol (BGP) peer can send a crafted UPDATE message containing a martian next-hop address that the daemon fails to validate. This triggers a Denial of Service (DoS) condition in the bgpd process. The issue is tracked under [CWE-20: Improper Input Validation].

Critical Impact

An authenticated BGP neighbor can disrupt routing availability by sending a crafted UPDATE message that causes the FRR bgpd daemon to enter an unsafe state, impacting network reachability for downstream peers.

Affected Products

• FRRouting (FRR) stable/10.0
• FRRouting (FRR) stable/10.1 through stable/10.5
• FRRouting (FRR) stable/10.6

Discovery Timeline

• 2026-05-04 - CVE-2026-37458 published to NVD
• 2026-05-05 - Last updated in NVD database

Technical Details for CVE-2026-37458

Vulnerability Analysis

The vulnerability resides in the BGP attribute parser inside bgpd/bgp_attr.c. When FRR processes an incoming BGP UPDATE message, the MP_REACH_NLRI (Multiprotocol Reachable Network Layer Reachability Information) attribute carries the next-hop address used to reach advertised prefixes. The pre-patch code path for BGP_ATTR_NHLEN_IPV4 reads the next-hop directly into attr->mp_nexthop_global_in without checking whether the address is a martian (reserved, loopback, multicast, or otherwise invalid for use as a next-hop).

FRR already performs martian validation on the legacy NEXT_HOP attribute, but the multiprotocol equivalent lacked the same check. An authenticated BGP peer with an established session can exploit this gap to influence parser state with invalid data, leading to a Denial of Service on the routing daemon.

Root Cause

The root cause is missing input validation on the IPv4 next-hop carried inside the MP_REACH_NLRI attribute. The parser trusted peer-supplied data without applying the same ipv4_martian() check used for the classic NEXT_HOP path, creating an inconsistency between the two code paths.

Attack Vector

Exploitation requires an authenticated BGP session with the target FRR instance. A peer crafts a BGP UPDATE message embedding an invalid IPv4 address inside the MP_REACH_NLRI attribute. The bgpd daemon parses the message and processes the unvalidated next-hop, resulting in a denial of service against routing services.

// Security patch in bgpd/bgp_attr.c
// Source: https://github.com/FRRouting/frr/commit/8102a8aeceb9f86fdfe1f80cd77080522bab69c8
		fallthrough;
 	case BGP_ATTR_NHLEN_IPV4:
 		stream_get(&attr->mp_nexthop_global_in, s, IPV4_MAX_BYTELEN);
+
+		/* We do already the same validation for NEXT_HOP attribute,
+		 * so let's do it here as well for consistency and to avoid potential
+		 * security issues with martian addresses in MP_REACH_NLRI.
+		 */
+		if (ipv4_martian(&attr->mp_nexthop_global_in) && !peer->bgp->allow_martian) {
+			zlog_warn("%s sent martian nexthop %pI4 in MP_REACH_NLRI", peer->host,
+				  &attr->mp_nexthop_global_in);
+			return BGP_ATTR_PARSE_WITHDRAW;
+		}
+
 		/* Probably needed for RFC 2283 */
 		if (attr->nexthop.s_addr == INADDR_ANY)
 			memcpy(&attr->nexthop.s_addr,

The patch adds an ipv4_martian() check immediately after reading the next-hop, returning BGP_ATTR_PARSE_WITHDRAW when an invalid address is detected and the allow_martian knob is disabled.

Detection Methods for CVE-2026-37458

Indicators of Compromise

• Unexpected restarts or crashes of the FRR bgpd process accompanied by core dumps in /var/log/frr/ or system journal entries.
• BGP session resets or repeated Notification messages logged shortly after receiving UPDATE messages from a specific peer.
• Log entries referencing martian next-hop addresses in MP_REACH_NLRI once the patched build is in place (e.g., sent martian nexthop ... in MP_REACH_NLRI).

Detection Strategies

• Inspect BGP UPDATE messages for MP_REACH_NLRI attributes containing reserved, loopback, multicast, or 0.0.0.0 next-hop values.
• Correlate bgpd daemon termination events with the timestamps of inbound BGP UPDATE traffic from each configured neighbor.
• Monitor route processor CPU and memory usage for anomalies that align with peer UPDATE bursts.

Monitoring Recommendations

• Enable verbose BGP debug logging (debug bgp updates in) on a controlled basis to capture suspicious attribute payloads.
• Forward FRR syslog output to a centralized logging or SIEM platform and alert on bgpd restart events.
• Track BGP neighbor uptime and flap counters via SNMP or vtysh -c "show bgp summary" to detect repeated resets.

How to Mitigate CVE-2026-37458

Immediate Actions Required

• Upgrade FRRouting to a release containing commit 8102a8aeceb9f86fdfe1f80cd77080522bab69c8 or a later stable patch level.
• Audit configured BGP neighbors and remove or restrict any sessions with peers that are not strictly required.
• Apply BGP authentication (TCP-AO or MD5) and enforce route filters to limit which prefixes and attributes peers can inject.

Patch Information

The fix is committed upstream in the FRRouting repository. The patched parser validates the IPv4 next-hop in MP_REACH_NLRI using ipv4_martian() and returns BGP_ATTR_PARSE_WITHDRAW for invalid addresses unless the operator explicitly enables allow_martian. Reference: FRRouting commit 8102a8ae and the public advisory writeup.

Workarounds

• Restrict BGP peering to authenticated, trusted neighbors and apply strict inbound route-map and prefix-list filters.
• Deploy infrastructure access control lists (iACLs) that limit TCP/179 reachability to known peer addresses.
• Ensure the allow_martian option remains disabled so the patched code path drops invalid next-hop values.

# Verify FRR version and confirm the patched commit is included
vtysh -c "show version"
git -C /usr/src/frr log --oneline | grep 8102a8ae

# Confirm allow_martian is not enabled (default)
vtysh -c "show running-config" | grep -i martian