CVE-2026-5107: FRRouting Auth Bypass Vulnerability

CVE-2026-5107 Overview

A vulnerability has been identified in FRRouting (FRR) up to version 10.5.1 that affects the process_type2_route function within the bgpd/bgp_evpn.c file of the EVPN Type-2 Route Handler component. This improper access control vulnerability (CWE-266: Incorrect Privilege Assignment) allows remote attackers to potentially manipulate routing information, though exploitation is considered difficult due to high attack complexity and requires low-level privileges.

Critical Impact

Attackers with network access and low privileges could exploit insufficient validation in EVPN route processing to cause limited integrity and availability impacts on affected FRRouting deployments.

Affected Products

• FRRouting FRR versions up to 10.5.1
• Systems running BGP daemon with EVPN functionality enabled
• Network infrastructure utilizing FRR for BGP routing

Discovery Timeline

• 2026-03-30 - CVE-2026-5107 published to NVD
• 2026-03-30 - Last updated in NVD database

Technical Details for CVE-2026-5107

Vulnerability Analysis

This vulnerability resides in the EVPN (Ethernet VPN) Type-2 route processing functionality within FRRouting's BGP daemon. EVPN Type-2 routes are used to advertise MAC and IP address information across a BGP network, making proper validation critical for network integrity. The flaw stems from insufficient validation of the IP address length field within EVPN Network Layer Reachability Information (NLRI) packets before processing, which could allow an authenticated remote attacker to cause limited integrity and availability impacts on the routing infrastructure.

The vulnerability requires network access and low-level authentication, combined with high attack complexity, making practical exploitation challenging but not impossible in targeted scenarios against vulnerable network infrastructure.

Root Cause

The root cause is improper access control (CWE-266) in the EVPN route parsing logic. Specifically, the process_type2_route function in bgpd/bgp_evpn.c failed to properly validate the ipaddr_len field against the actual NLRI packet size before processing. This missing validation allowed malformed EVPN Type-2 and Type-4 routes to bypass proper boundary checks, potentially leading to incorrect route processing behavior.

Attack Vector

The attack can be initiated remotely over a network connection by sending specially crafted BGP EVPN route updates to a vulnerable FRRouting instance. The attacker must have at least low-level privileges (such as an established BGP peering session) to send route updates. Due to the high complexity nature of the attack, successful exploitation requires:

1. Establishing a BGP session with the target FRR router
2. Crafting malformed EVPN Type-2 or Type-4 NLRI packets with invalid IP address length values
3. Sending the malicious route updates through the established BGP session

The following code from the security patch demonstrates the fix that validates NLRI length against IP address length:

 		goto fail;
 	}
 
+	/* Validate ipaddr_len against the NLRI length */
+	if ((psize != 33 + (ipaddr_len / 8)) && (psize != 36 + (ipaddr_len / 8))) {
+		flog_err(EC_BGP_EVPN_ROUTE_INVALID,
+			 "%u:%s - Rx EVPN Type-2 NLRI with invalid IP address length %d",
+			 peer->bgp->vrf_id, peer->host, ipaddr_len);
+		goto fail;
+	}
+
 	if (ipaddr_len) {
 		ipaddr_len /= 8; /* Convert to bytes. */
 		p.prefix.macip_addr.ip.ipa_type = (ipaddr_len == IPV4_MAX_BYTELEN)

Source: GitHub Commit Details

Similarly, the Type-4 route handler received validation improvements:

 	memcpy(&esi, pfx, ESI_BYTES);
 	pfx += ESI_BYTES;
 
 	/* Get the IP. */
 	ipaddr_len = *pfx++;
+
+	/* Validate */
+	if (psize != 19 + (ipaddr_len / 8)) {
+		flog_err(EC_BGP_EVPN_ROUTE_INVALID,
+			 "%u:%s - Rx EVPN Type-4 NLRI with invalid IP address length %d",
+			 peer->bgp->vrf_id, peer->host, ipaddr_len);
+		return -1;
+	}
+
 	if (ipaddr_len == IPV4_MAX_BITLEN) {
 		SET_IPADDR_V4(&vtep_ip);
 		memcpy(&vtep_ip.ipaddr_v4, pfx, IPV4_MAX_BYTELEN);

Source: GitHub Commit Details

Detection Methods for CVE-2026-5107

Indicators of Compromise

• Unusual BGP EVPN route updates with malformed or inconsistent IP address length fields
• Error messages in FRR logs containing EC_BGP_EVPN_ROUTE_INVALID entries
• Unexpected BGP session resets or routing table inconsistencies
• Network traffic analysis showing EVPN NLRI packets with mismatched length values

Detection Strategies

• Monitor FRRouting log files for EVPN route parsing errors referencing invalid IP address lengths
• Implement BGP session monitoring to detect anomalous route update patterns from peers
• Deploy network intrusion detection systems (IDS) with rules for malformed BGP EVPN packets
• Audit BGP peer relationships to identify potentially malicious or compromised peering sessions

Monitoring Recommendations

• Enable verbose logging for the BGP daemon to capture EVPN route processing errors
• Configure alerting on EC_BGP_EVPN_ROUTE_INVALID error codes in system logs
• Regularly review BGP peer statistics for unusual route update volumes or error rates
• Implement centralized log collection from all FRR routing instances for correlation analysis

How to Mitigate CVE-2026-5107

Immediate Actions Required

• Upgrade FRRouting to a patched version that includes commit 7676cad65114aa23adde583d91d9d29e2debd045
• Review and restrict BGP peer relationships to trusted, authenticated sources only
• Enable BGP authentication (MD5 or TCP-AO) on all peering sessions
• Audit current EVPN configurations and peer trust relationships

Patch Information

The vulnerability has been addressed in the FRRouting project through commit 7676cad65114aa23adde583d91d9d29e2debd045. This patch adds proper validation of the ipaddr_len field against the actual NLRI packet size for both EVPN Type-2 and Type-4 routes. Organizations should apply this patch or upgrade to a version containing this fix. For detailed patch information, refer to the GitHub Pull Request and GitHub Commit Details.

Workarounds

• Implement strict BGP prefix filtering to limit which peers can send EVPN routes
• Configure route-maps to validate EVPN route attributes before accepting updates
• Deploy network segmentation to isolate routing infrastructure from untrusted networks
• Consider disabling EVPN functionality if not required in your deployment

# Configuration example - Enable BGP MD5 authentication for peer sessions
vtysh -c "configure terminal" \
      -c "router bgp <ASN>" \
      -c "neighbor <PEER_IP> password <STRONG_PASSWORD>" \
      -c "end" \
      -c "write memory"