CVE-2026-30405: 
NixOS vulnerability analysis and mitigation

CVE-2026-30405 is a denial-of-service vulnerability in GoBGP (gobgpd) v4.2.0 that allows a remote, unauthenticated attacker to crash the BGP daemon by sending a malformed BGP UPDATE message containing a NEXT_HOP path attribute with an invalid length (less than 4 bytes). The issue was reported on January 27, 2026, and published to NVD on March 16, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Issue, Feedly).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) with an estimated CWE-476 (NULL Pointer Dereference) component. When GoBGP receives a BGP UPDATE message containing a NEXT_HOP path attribute with AttrLen set to 0, 1, 2, or 3 (instead of the RFC 4271-mandated 4 bytes), the daemon partially accepts and processes the malformed attribute, constructing an internally inconsistent PathAttributeNextHop object. This misaligned state causes an out-of-bounds index access (index out of range [0] with length 0) during subsequent AS_PATH validation in ValidateAttribute (file pkg/packet/bgp/validate.go, line 138/152), triggering a Go runtime panic and crashing the gobgpd process. Exploitation requires only an established EBGP session with the target — no authentication beyond BGP peering is needed (GitHub Issue).

Successful exploitation causes the gobgpd daemon to panic and terminate, rendering the BGP routing service completely unavailable (availability impact: High). There is no confidentiality or integrity impact — the vulnerability is purely a denial-of-service condition. In network environments relying on GoBGP for route distribution or traffic engineering, a crash could disrupt routing convergence, cause traffic blackholing, or destabilize peering relationships until the daemon is manually restarted (GitHub Issue, Feedly).

A proof-of-concept exploit with concrete reproduction steps and a hex payload is publicly available on GitHub, demonstrating how to trigger the panic by establishing an EBGP session and sending a crafted UPDATE message (GitHub Issue). The exploit requires no privileges and no user interaction, only network access to an EBGP peer. As of the time of reporting, there is no evidence of active in-the-wild exploitation, and no threat actor attribution has been made. The EPSS score is approximately 0.0014 (0.14%), indicating low but non-zero exploitation probability. The vulnerability is not listed in the CISA KEV catalog (Feedly).

1. Reconnaissance: Identify hosts running GoBGP gobgpd v4.2.0 that are reachable via BGP (port 179/TCP). Scan for open BGP ports using tools like Nmap or Masscan.
2. Establish EBGP session: Configure a BGP peer to establish an EBGP session with the target GoBGP instance. Wait for the session to reach the BGP_FSM_ESTABLISHED state.
3. Craft malformed UPDATE message: Construct a BGP UPDATE message containing a NEXT_HOP path attribute (type code 0x03) with AttrLen set to a value less than 4 (e.g., 0, 1, 2, or 3). Example hex payload from the PoC: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 28 02 00 00 00 0d 40 01 01 02 40 02 00 40 03 02 01 02 01 18 c0 a8 01 (where 40 03 02 sets NEXT_HOP with AttrLen=2).
4. Send the malformed UPDATE: Transmit the crafted UPDATE message to the target over the established BGP session.
5. Trigger panic: GoBGP processes the malformed attribute, reaches ValidateAttribute in validate.go, and panics with a runtime out-of-bounds error, crashing the gobgpd process and taking down the BGP routing service (GitHub Issue).

• Logs: gobgpd log entries showing "msg":"the received Update message was treated as withdraw" followed immediately by a Go runtime panic: panic: runtime error: index out of range [0] with length 0 in gobgp/pkg/packet/bgp/validate.go.
• Logs: Stack trace referencing ValidateAttribute.func2 at validate.go:138 and ValidateUpdateMsg at validate.go:35 in the gobgpd process logs.
• Process: Unexpected termination or restart of the gobgpd process, particularly following BGP UPDATE messages from a peer.
• Network: BGP UPDATE messages (TCP port 179) from a peer containing a NEXT_HOP path attribute (type code 0x03) with an attribute length field less than 4 bytes; these can be detected via BGP-aware IDS signatures or packet capture analysis (GitHub Issue).

Users should upgrade GoBGP gobgpd to a version beyond 4.2.0 that includes a fix for NEXT_HOP attribute length validation (patch details reference the GitHub issue #3305). As a network-level workaround where immediate patching is not possible, restrict BGP peering to only trusted, known peers using firewall rules or BGP session authentication (e.g., MD5 TCP-AO), which reduces the attack surface by limiting who can establish an EBGP session. Additionally, monitoring for unexpected gobgpd process crashes and implementing automatic process restart (e.g., via systemd) can reduce downtime impact (GitHub Issue, Feedly).