UBUNTU-CVE-2026-120033: Medium severity ubuntu/quagga vulnerability

Published Nov 13, 2026
·
Updated

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 Software

8 affected components
ubuntu/quagga*
ubuntu/quagga*
ubuntu/quagga*
ubuntu/frr*
ubuntu/frr*
ubuntu/frr*
ubuntu/frr*
ubuntu/frr*

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Operational

    Manually clear the BGP session to allow the neighbor to reconnect.

Event History

Nov 13, 2026
CVE Published
via OSV·12:00 AM
Data Sourced
via OSV·12:00 AM
DescriptionSeverityAffected Software

Frequently Asked Questions

1

Which deployments are exposed by default?

Any router with an established BGP neighbor is affected; no special configuration is required. Graceful Restart helper mode is enabled by default, which makes the crash outcome possible when the peer has announced Graceful Restart support.

2

What must a peer do to trigger the issue?

The peer must keep sending BGP KEEPALIVEs while no longer accepting data from the router, during a period when the router has substantial data to send, such as a full routing-table transfer. This can be caused by a malicious peer, but also by an overloaded or stuck neighbor.

3

What is the impact if the peer supports Graceful Restart?

If the peer announced Graceful Restart support, bgpd crashes shortly after the connection closes. This takes down all BGP sessions on the router, and the peer can trigger the condition again after bgpd restarts.

4

What happens without Graceful Restart support, and what can operators do?

The affected session remains stuck in Established state: its routes stay installed and continue to be advertised to other peers, while the neighbor cannot reconnect. An operator must manually clear the session to recover it.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203