FRR BGP MP_REACH_NLRI Bug CVE-2023-46752 Patch and Mitigation

An input‑validation bug in the FRRouting (FRR) BGP code — tracked as CVE‑2023‑46752 — allows specially crafted BGP UPDATE attributes (malformed MP_REACH_NLRI data) to crash the bgpd daemon, producing a denial‑of‑service condition for affected routers and appliances. Patches merged into upstream FRR change the behavior from crashing to politely rejecting malformed attributes (and resetting the session), but operators who run unpatched releases up to and including FRR 9.0.1 remain at risk until their distributions or vendors deliver updates.

---

Background​

FRRouting (commonly known as FRR or frr) is an open‑source routing suite that implements BGP, OSPF, IS‑IS and other control‑plane protocols. It is widely used in cloud, ISP, virtual router, and appliance deployments where Linux/BSD hosts perform production routing duties. A crash in a routing daemon can have immediate and measurable operational consequences — route withdrawal, traffic blackholing, and cascading failover events — which is why even a relatively modest severity CVE can carry outsized operational risk for infrastructure providers.
CVE‑2023‑46752 was publicly disclosed on October 26, 2023. The vulnerability description is concise: FRRouting FRR through 9.0.1 mishandles malformed MP_REACH_NLRI data, leading to a crash. Multiple downstream distributors and advisories (Ubuntu, Debian, SUSE, Oracle Linux) catalog the same description and assign a medium CVSS score (base 5.9) with an availability‑only impact.

---

What MP_REACH_NLRI is, and why malformed data matters​

BGP basics, in a paragraph​

The Border Gateway Protocol (BGP) exchanges reachability information between peers using UPDATE messages. An UPDATE includes path attributes and NLRI (Network Layer Reachability Information). The MP_REACH_NLRI attribute is a multi‑protocol extension used to carry next‑hop and NLRI for address families beyond basic IPv4 unicast (for example IPv6, VPNv4, EVPN). MP_REACH_NLRI contains subfields (AFI/SAFI, next‑hop, and a sequence of NLRI entries) that must be parsed carefully. If an implementation trusts attribute length fields or copies unvalidated bytes into fixed‑length buffers, a malformed attribute can provoke a crash. (github.com)

Where FRR went wrong​

The FRR bug stems from insufficient validation around MP_REACH_NLRI parsing inside bgpd: when a crafted MP_REACH_NLRI attribute contains inconsistent lengths or missing mandatory pieces, FRR's parsing path could proceed to copy bytes into structures without verifying that the stream had enough readable bytes. That behavior led to a segmentation fault in bgpd in real‑world traces and deliberate tests. The upstream fix changes the parsing path so that malformed MP_REACH_NLRI attributes trigger a parse‑error handler which results in session reset or update notification rather than continuing into unsafe memory operations. (github.com)

---

The fix: what upstream changed​

Upstream FRR merged a targeted patch (pull request #14645) that performs two complementary changes: stricter attribute‑length checks during MP_REACH_NLRI parsing, and moving error paths to a malformed attribute handler which issues a BGP notify and resets the session instead of returning values that lead to later unsafe code paths. The commit titled "bgpd: Handle MP_REACH_NLRI malformed packets with session reset" (commit b08afc8) summarizes the behavior change and links the crash trace that motivated the change. In short: the project replaced a risky return code with an explicit malformed‑attribute handler and removed code paths that earlier let execution continue after encountering an ill‑formed MP_REACH_NLRI. (github.com)
Downstream distributions incorporated the upstream commits into patched binary packages (Ubuntu USNs and Debian LTS advisories document specific package versions). Where vendors bundled older FRR branches, they issued package updates that include the upstream commit or equivalent backports. Operators should verify their distribution's specific fix level before assuming the package is patched.

---

Impact assessment: availability, exploitability, and exposure​

Availability impact​

The vulnerability has no confidentiality or integrity effects — it is an availability problem: a successful trigger causes bgpd to crash, which removes the router's BGP routes from the routing table until the daemon restarts or the system fails over. For edge routers and core peers, that can mean new connections fail or traffic is blackholed; for providers, the outage can cascade. Vendors and CVE trackers characterize the impact as High for availability despite an overall medium CVSS base score, because the real‑world operational cost is significant even though exploitation does not confer code execution or data theft.

Exploitability and attack complexity​

Exploiting MP_REACH_NLRI parsing requires the attacker to send crafted BGP UPDATE messages into a session that the vulnerable bgpd will parse. Practically, that means the attacker must either:

• be a legitimate BGP neighbor (i.e., have an established session), or
• be able to inject packets into an existing BGP session (man‑in‑the‑middle), or
• be upstream of a misconfigured peering point that accepts unauthenticated updates.

Because establishing a BGP session with a target typically requires configuration and sometimes operational controls (peering agreements, session filters, authentication), many trackers list Attack Complexity = High. That reduces the likelihood of mass internet‑scale exploitation but doesn’t eliminate real risk to networks with poorly guarded peering points, misconfigurations, or where untrusted peers are accepted. In short: the exploit is realistic in hostile or misconfigured environments but not an "anyone on the Internet" trivial exploit.

Which versions are affected​

Upstream FRR releases through and including 9.0.1 are listed as affected; the commit that remedied the parsing issue was merged on Oct 25, 2023. However, downstream distribution packaging complicates the picture: many distributions ship older FRR releases with vendor backports or provide their own patches and version numbers. Operators must consult their distribution's security notice for the exact fixed package version rather than assuming any FRR version string corresponds directly to the upstream release number. Ubuntu, Debian LTS, SUSE and Oracle Linux all published advisories reflecting that nuance. (github.com)

---

Realistic attack scenarios​

• An untrusted peer: A router configured to accept external BGP (eBGP) sessions without strict source ACLs or with permissive filters may accept a malicious neighbor that sends crafted UPDATEs. Once a malformed MP_REACH_NLRI is injected, the remote bgpd could crash. This is most dangerous in edge routers that have public peering.
• On‑path injection: In environments where BGP sessions are not protected by TCP MD5 or TCP‑AO and where an attacker can alter or inject traffic in transit (e.g., compromised IX or misconfigured transit), crafted attributes could be injected into an existing session. This is a higher‑sophistication attack but is feasible for targeted adversaries.
• Internal threat or misconfiguration: An internally compromised host or misconfigured device that can originate BGP updates represents the lowest barrier: internal agents often have fewer protections and can trivially push crafted updates. In multi‑tenant cloud or large campus setups, internal vectors are non‑trivial.

No public exploit code tied to CVE‑2023‑46752 was widely reported at disclosure time, and vulnerability databases show low EPSS/exploitation prediction values; nevertheless, CVE publication followed by availability of proof‑of‑concepts or exploit toolkits could raise risk over time. Patch and operational hardening are the most reliable mitigations.

---

Detection, monitoring, and indicators​

Detecting attempted exploitation will look like anomalous BGP UPDATE patterns and repeated session resets from peers. Practical signals include:

• Repeated BGP session flaps coinciding with receipt of oddly small/large UPDATE messages or UPDATE messages flagged as malformed by the bgpd logs. Modern FRR logs include messages showing attribute parse errors which can be searched for. (github.com)
• Intrusion detection systems and network anomaly detectors that inspect BGP messages (e.g., Bro/Zeek scripts, BGP monitoring tools) can be tuned to flag unusual MP_REACH_NLRI lengths, unexpected AFI/SAFI combinations, or UPDATE messages containing attributes of inconsistent length. Deploy signatures or heuristics to raise alerts when MP_REACH_NLRI length fields do not match the message size.
• Monitoring service availability and route convergence metrics: sudden route withdrawals, a rise in route churn, or unexplained peer restarts correlate with this class of issue. Consider synthetic workflows to verify BGP session health and route availability continuously.

If you see repeated session resets that line up with malformed‑attribute warnings in logs, treat that as high‑confidence evidence of attempted exploitation or accidental malformed traffic. Capture full pcaps of the offending updates for forensic analysis before you restart services if operationally feasible.

---

Mitigation and remediation: prioritized playbook​

Apply fixes as the most effective mitigation step. But because patch delivery can be delayed in some vendors or in heavily constrained environments, apply short‑ and medium‑term operational controls.

• Patch first (highest priority)
• Update FRR to a version that includes the upstream fix (the upstream commits referenced in PR #14645). If you use a distribution package, apply the vendor security update (Ubuntu USN, Debian DLA, SUSE/Oracle advisories list fixed package numbers). Confirm the package includes the upstream commit or an equivalent backport. (github.com)
• If you cannot patch immediately, apply operational controls (recommended)
• Restrict BGP peering to authenticated, trusted peers only. Use TCP MD5 or TCP‑AO where possible to prevent session injection or spoofing.
• Harden peering policies: accept routes only from known prefixes, apply strict inbound filters that drop unexpected AFI/SAFI combinations, and set maximum prefix counts and route‑limit alarms.
• Block unknown or unauthorised on‑net peers at the network edge with ACLs and route‑filters.
• If you do not use multiprotocol AFIs (e.g., IPv6 or VPNv4) on a given session, configure the peer to refuse MP_REACH_NLRI or filter out those attributes. Note: this is a work‑around and can break legitimate multiprotocol use if applied carelessly.
• Operational best practices (medium term)
• Instrument bgpd logging and NMS to alert on parse errors or repeated session resets.
• Maintain inventory of all systems running FRR (including container images and virtual appliances) so patches are rolled out comprehensively.
• Apply configuration‑management to ensure consistent peer filters and MD5/TCP‑AO across peering fabric.
• When possible, prefer vendor‑validated images for routers and virtual appliances rather than community builds for production core infrastructure.

---

Recommendations for cloud, ISP, and appliance operators​

• Treat this as a routing‑plane availability event: prioritize patching on border and peering routers even if they run stable, long‑running processes. A single bgpd crash in a core session may produce an outage far larger than a non‑routing service crash.
• Validate the fix in staging using representative peering topologies before pushing to production. The upstream patch changes failure semantics (session reset on malformed attribute) — test how your control plane reacts to session resets and whether automation will restart bgpd correctly. (github.com)
• If you provide peering to external customers or operate IX points, enforce strict peering policies: require operational contacts, RPKI origin validation where appropriate, and use prefix/AS‑path filters to reduce attack surface. Public peers accepted without authentication are prime vectors for crafted updates.
• Run continuous route‑monitoring and deploy BGP monitoring platforms (looking‑glass, RPKI status, telemetry of prefix counts) to notice the subtle onset of routing anomalies that might follow an exploitation attempt.

---

Detection playbook: concrete steps for SOCs and NOC teams​

• Add signature/heuristic rules in network IDS/IPS to flag BGP UPDATE messages with inconsistent MP_REACH_NLRI length fields or unexpected AFI/SAFI identifiers. If your IDS supports protocol dissectors, require alerts for MP_REACH_NLRI where next‑hop field lengths do not match expected AFI.
• Configure FRR to log attribute parse errors at an elevated level; centralize these logs to the SIEM and create an alert when parse errors or BGP_ATTR_PARSE_ERROR entries appear more than once per minute from the same peer. (github.com)
• When parsing failures and session resets are detected, capture a pcap of the session and preserve it alongside the bgpd logs. The packet capture is essential for forensic reconstruction and for providing actionable data to vendors or peers.
• Automate a controlled restart path for bgpd so that a single crash does not result in prolonged downtime; however, pair automated restarts with alarms and human escalation so persistent crashes are not masked by restart loops.

---

Why this matters: operational risk beyond the CVSS number​

CVE scores are useful for triage but can understate operational risk when they omit real‑world availability consequences. A CVSS base score of 5.9 (medium) reflects technical severity absent confidentiality or integrity loss. For operators, the practical consequence — removal of routing state — often translates to business severity far higher than the numeric score, because routing outages disrupt many downstream services and can be difficult to remediate quickly at scale. This mismatch is why network teams must treat routing CVEs with a heightened sense of urgency compared with many application‑level vulnerabilities.

---

Checklist: what to do right now​

• Inventory: identify every host, appliance, container image, and vendor image that runs FRR or includes bgpd. Confirm the exact package version or commit SHA.
• Patch: apply the distribution or vendor update that contains the upstream fix (PR #14645 / commit b08afc8). If vendor packages are unavailable, follow vendor guidance for backports or compensating controls. (github.com)
• Harden peering: require MD5/TCP‑AO, tighten import filters, and disable unused MP capabilities.
• Monitor: add log and network alerts for parse errors and peer session flaps; capture traffic for any suspicious events. (github.com)
• Validate: test the fix in a staging environment and confirm your automation handles session resets gracefully. (github.com)

---

Final analysis: strengths of the fix, remaining risks​

The upstream FRR fix demonstrates a sensible, surgical remediation: validate input early, and if malformed attributes are detected, treat them as parse errors that trigger BGP notify/session reset semantics. That is the correct operational behavior for a resilient control plane: refuse malformed data and fail the session cleanly instead of continuing into unsafe memory operations. The PR and commit are transparent and include crash traces and tests, which is an operational strength for maintainers and downstream vendors. (github.com)
Remaining risks include:

• Lag between upstream fixes and vendor/distribution package rollouts — some operators run vendor images or appliances that bundle older FRR code, so patch windows can be substantial. Verify vendor advisories for fixed package versions.
• Operational misconfigurations that accept unauthenticated external peers or lack strict import filters — these configurations remain the primary avenue for exploitation even after a fix is broadly available. Hardening peering and minimizing the set of peers that can inject MP_REACH_NLRI is essential.
• Detection gaps: many NOCs do not inspect BGP payloads in transit. If your tooling looks only at session state and not message content, attempts to exploit parsing subtleties might go unnoticed apart from the crash itself. Logging and IDS signatures need to be tuned.

If you have an exposure that cannot be patched immediately, treat the vulnerability as a high‑impact availability risk and prioritize controls around peering hardening, session authentication, and monitoring.

---

CVE‑2023‑46752 is a textbook example of how small input‑validation errors in control‑plane code translate quickly to outsized operational risk. The upstream patch is correct and narrowly scoped; the real work for operators is inventory, coordinated patching, and tightening peering controls so a single malformed UPDATE cannot take down critical routing services. Act quickly, test safely, and monitor continuously. (github.com)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center