CVE-2026-30405: Osrg Gobgp DOS Vulnerability

CVE-2026-30405 Overview

CVE-2026-30405 is a denial of service vulnerability affecting GoBGP gobgpd version 4.2.0. GoBGP is an open-source Border Gateway Protocol (BGP) implementation written in Go and maintained by the osrg project. A remote attacker can trigger the condition by sending a crafted NEXT_HOP path attribute, causing the BGP daemon to become unavailable. The flaw is classified under CWE-400 (Uncontrolled Resource Consumption) and is exploitable over the network without authentication or user interaction.

Critical Impact
A remote, unauthenticated attacker can crash or hang the gobgpd process by sending a malformed NEXT_HOP path attribute, disrupting BGP routing for any peer running the affected version.

Affected Products

GoBGP gobgpd version 4.2.0
Deployments using osrg/gobgp as a BGP speaker or route reflector
Network infrastructure peering with vulnerable gobgpd instances

Discovery Timeline

2026-03-16 - CVE-2026-30405 published to the National Vulnerability Database (NVD)
2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-30405

Vulnerability Analysis

The vulnerability resides in the way gobgpd parses the BGP NEXT_HOP path attribute contained in UPDATE messages. BGP UPDATE messages carry routing information along with path attributes that describe each route. The NEXT_HOP attribute (type code 3) specifies the IP address of the next-hop router for advertised prefixes.

When gobgpd 4.2.0 processes a malformed or unexpected NEXT_HOP attribute, the daemon enters a condition that exhausts available resources or terminates processing. The defect maps to CWE-400, Uncontrolled Resource Consumption. Refer to the upstream GitHub issue 3305 for the maintainer discussion.

Root Cause

The root cause is insufficient validation of the NEXT_HOP path attribute during BGP UPDATE message decoding. The parser does not enforce all structural and semantic constraints expected by the BGP specification, allowing a crafted attribute to push the daemon into an unrecoverable state.

Attack Vector

Exploitation requires a BGP session between the attacker-controlled peer and the target gobgpd instance. After the session is established, the attacker sends an UPDATE message containing the malformed NEXT_HOP attribute. Because BGP peering is typically pre-authorized by configuration rather than authenticated per message, any configured peer can trigger the condition. Successful exploitation causes a denial of service against the routing daemon.

No public proof-of-concept or weaponized exploit is currently available. See the GoBGP issue tracker for technical context.

Detection Methods for CVE-2026-30405

Indicators of Compromise

Unexpected restarts, crashes, or hangs of the gobgpd process on systems running version 4.2.0
BGP session resets (NOTIFICATION messages or TCP RST) immediately after receiving an UPDATE from a peer
Sudden withdrawal of advertised routes followed by peer session flapping

Detection Strategies

Inspect BGP UPDATE messages at network ingress for NEXT_HOP attributes that violate length or address-family expectations
Correlate gobgpd process termination events with the timing of inbound BGP traffic from specific peers
Enable verbose logging in gobgpd to capture attribute parsing failures and malformed message events

Monitoring Recommendations

Alert on gobgpd service restarts and abnormal CPU or memory consumption on routing hosts
Monitor BGP session uptime metrics and flag peers that repeatedly trigger session resets
Forward gobgpd logs and host telemetry to a centralized analytics platform for correlation across BGP speakers

How to Mitigate CVE-2026-30405

Immediate Actions Required

Identify all hosts running gobgpd 4.2.0 and prioritize them for upgrade once a fixed release is available
Restrict BGP peering to trusted, authenticated neighbors using tcp-md5 or BGP authentication keys
Apply ingress filters and route policies that constrain accepted attributes from external peers

Patch Information

At the time of publication, the upstream maintainers are tracking the issue in GoBGP GitHub issue 3305. Operators should monitor the osrg/gobgp repository for a release that supersedes version 4.2.0 and apply it as soon as it is published.

Workarounds

Terminate BGP sessions with untrusted or unnecessary peers until a fixed version is deployed
Use a BGP edge device or route server in front of gobgpd to validate and sanitize incoming UPDATE messages
Implement process supervision (for example, systemd automatic restart) to reduce outage duration if the daemon crashes

bash

# Example systemd override to auto-restart gobgpd after a crash
# /etc/systemd/system/gobgpd.service.d/restart.conf
[Service]
Restart=always
RestartSec=5s
StartLimitIntervalSec=60
StartLimitBurst=10