CVE-2026-120033
frr: bgpd Send Hold Timer expiry bypasses the FSM, leaving a phantom Established session or crashing bgpd with Graceful Restart
Published Nov 12, 2026
CVSS 4.0 · 6 Medium
EPSS < 1%
KEV · Not listed
Description
In FRRouting 10.1 and later, bgpd does not correctly close a BGP session when the Send Hold Timer (RFC 9687) expires, i.e. when a neighbor has stopped accepting data from the router for twice the hold time. The connection is closed, but bgpd still considers the session to be up. A BGP neighbor that keeps sending KEEPALIVEs but stops reading from its connection, at a time when the router has a large amount of data to send to it (for example while sending it a full routing table), can trigger this. If the neighbor announced Graceful Restart support, bgpd crashes shortly after the session is closed, taking down all BGP sessions on the router, and the neighbor can repeat this each time bgpd restarts. Otherwise, the session stays stuck in the Established state: the neighbor's routes stay installed and keep being advertised to other peers, and the neighbor cannot reconnect until an operator clears the session manually. The neighbor does not need to be malicious; an overloaded or stuck peer can trigger the same behavior. No special configuration is required: any established BGP neighbor can trigger the issue, and Graceful Restart helper mode, which leads to the crash, is enabled by default.
Affected Products
-
CVE record
-
NVD configurations
No data
-
Red Hat packages
No data
-
OpenCVE enrichment
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| frrouting | frrouting | unaffected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Frrouting | Frrouting |
|
Remediation
Vendor Workaround
No configuration workaround fully prevents the issue. Monitor bgpd logs for "has not made any SendQ progress for 2 holdtimes" and run "clear bgp <neighbor>" for the affected neighbor, which raises a real FSM event and recovers the peer (this does not prevent the abort when Graceful Restart was negotiated, if the restart timer fires first).
Tracking
Advisories
Metrics
Attack Vector Network
Attack Complexity Low
Privileges Required Low
Attack Requirements Present
User Interaction None
Vulnerable System Confidentiality Impact None
Vulnerable System Integrity Impact Low
Vulnerable System Availability Impact High
Subsequent System Confidentiality Impact None
Subsequent System Integrity Impact Low
Subsequent System Availability Impact Low
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.294% probability within 30 days)
Key SSVC decision points have not yet been added.
References
History
Nov 13, 2026 6:45 AM
Description updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In FRRouting 10.1 and later, bgpd does not correctly close a BGP session when the Send Hold Timer (RFC 9687) expires, i.e. when a neighbor has stopped accepting data from the router for twice the hold time. The connection is closed, but bgpd still considers the session to be up. A BGP neighbor that keeps sending KEEPALIVEs but stops reading from its connection, at a time when the router has a large amount of data to send to it (for example while sending it a full routing table), can cause one of the following: * If the neighbor announced Graceful Restart support: bgpd crashes shortly after the session is closed (after the neighbor's announced restart time plus one keepalive interval), taking down all BGP sessions on the router. The neighbor can repeat this each time bgpd restarts. * Otherwise: the session stays stuck in the Established state. The neighbor's routes stay installed and keep being advertised to other peers, and the neighbor cannot reconnect until an operator runs "clear bgp <neighbor>". The neighbor does not need to be malicious; an overloaded or stuck peer can trigger the same behavior. Required configuration: no special configuration is needed. Any BGP neighbor with an established session can trigger the issue under default settings, for example: router bgp 65001 neighbor 192.0.2.2 remote-as 65002 Graceful Restart helper mode, which leads to the crash, is enabled by default. With default timers (keepalive 60s, hold time 180s), the session is closed about 6 minutes after the neighbor stops reading. | In FRRouting 10.1 and later, bgpd does not correctly close a BGP session when the Send Hold Timer (RFC 9687) expires, i.e. when a neighbor has stopped accepting data from the router for twice the hold time. The connection is closed, but bgpd still considers the session to be up. A BGP neighbor that keeps sending KEEPALIVEs but stops reading from its connection, at a time when the router has a large amount of data to send to it (for example while sending it a full routing table), can trigger this. If the neighbor announced Graceful Restart support, bgpd crashes shortly after the session is closed, taking down all BGP sessions on the router, and the neighbor can repeat this each time bgpd restarts. Otherwise, the session stays stuck in the Established state: the neighbor's routes stay installed and keep being advertised to other peers, and the neighbor cannot reconnect until an operator clears the session manually. The neighbor does not need to be malicious; an overloaded or stuck peer can trigger the same behavior. No special configuration is required: any established BGP neighbor can trigger the issue, and Graceful Restart helper mode, which leads to the crash, is enabled by default. |
Nov 12, 2026 6:45 PM
Description updated. Title updated. First appearance in the feed. Weaknesses updated. Affected versions updated. Affected vendors updated. Added references. Scoring metrics updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In FRRouting 10.1 and later, bgpd does not correctly close a BGP session when the Send Hold Timer (RFC 9687) expires, i.e. when a neighbor has stopped accepting data from the router for twice the hold time. The connection is closed, but bgpd still considers the session to be up. A BGP neighbor that keeps sending KEEPALIVEs but stops reading from its connection, at a time when the router has a large amount of data to send to it (for example while sending it a full routing table), can cause one of the following: * If the neighbor announced Graceful Restart support: bgpd crashes shortly after the session is closed (after the neighbor's announced restart time plus one keepalive interval), taking down all BGP sessions on the router. The neighbor can repeat this each time bgpd restarts. * Otherwise: the session stays stuck in the Established state. The neighbor's routes stay installed and keep being advertised to other peers, and the neighbor cannot reconnect until an operator runs "clear bgp <neighbor>". The neighbor does not need to be malicious; an overloaded or stuck peer can trigger the same behavior. Required configuration: no special configuration is needed. Any BGP neighbor with an established session can trigger the issue under default settings, for example: router bgp 65001 neighbor 192.0.2.2 remote-as 65002 Graceful Restart helper mode, which leads to the crash, is enabled by default. With default timers (keepalive 60s, hold time 180s), the session is closed about 6 minutes after the neighbor stops reading. | |
| Title | frr: bgpd Send Hold Timer expiry bypasses the FSM, leaving a phantom Established session or crashing bgpd with Graceful Restart | |
| First Time appeared |
Frrouting
Frrouting frrouting |
|
| Weaknesses | CWE-372 CWE-617 |
|
| CPEs | cpe:2.3:a:frrouting:frrouting:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Frrouting
Frrouting frrouting |
|
| References |
| |
| Metrics |
cvssV4_0
|
