Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Found through variant analysis based on CVE-2026-41643 Summary GoBGP accepts a zero-length ASPATH during UPDATE decoding and later panics while validating that attribute for a confederation eBGP peer. The vulnerable path is in the BGP UPDATE validator: a malformed UPDATE that should be rejected as a malformed ASPATH instead reaches an unchecked p.Value[0] access, allowing a configured confederation eBGP peer to trigger a denial of service. Affected - Project: gobgp - Repo: https://github.com/osrg/gobgp - Pinned ref: c24629411ba49f160d9dc09126f418218127e016 Root cause An established peer's receive path reads BGP bytes from the network connection in pkg/server/fsm.go:1267, parses UPDATE bodies through the BGP message decoder, and validates decoded UPDATEs with peer state at pkg/server/fsm.go:1849. The UPDATE decoder walks the path-attribute list in pkg/packet/bgp/bgp.go:15773 and selects the concrete attribute parser from the attacker-controlled attribute type at…
Recommended action: Upgrade to 4.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GoBGP contains a BGP OPEN capability parsing issue where several concrete capability decoders may parse data from the full remaining capability buffer instead of the slice bounded by the declared capability length, CapLen. A malformed BGP OPEN message can cause bytes from a following capability to be interpreted as part of the current capability. The most security-relevant case is the 4-octet AS capability, where a capability with CapLen == 0 may cause the parser to read bytes from the following capability as the 4-octet AS value. This parsed value may later affect peer AS validation during BGP session establishment. Details The issue is in the BGP OPEN capability parser under: - pkg/packet/bgp/bgp.go - pkg/packet/bgp/validate.go - The BGP OPEN optional parameter capability format includes a capability code, a capability length field, and a capability value. Each concrete capability decoder should only parse bytes inside the declared capability value boundary. In affected…
Recommended action: Upgrade to 4.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An integer underflow in the BGPUpdate.DecodeFromBytes function (/bgp/bgp.go) of gobgp v4.3.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted BGP UPDATE message.
Recommended action: Upgrade to 4.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Remote Denial of Service (DoS) via Nil Pointer Dereference in BGP Update Processing An unauthenticated remote BGP peer can trigger a fatal panic in GoBGP by sending a specially crafted BGP UPDATE message. When the server receives a message with inconsistent attribute lengths, it improperly handles the internal state transition to a "withdraw" action, leading to a nil pointer dereference in the AdjRib.Update function. This causes the entire GoBGP process to crash, resulting in a complete loss of service availability. Details The vulnerability originates in the interaction between the BGP message decoding logic and the Adj-RIB table management. Triggering Condition: When a BGP UPDATE message contains attributes that fail validation (e.g., "attribute value length is short"), GoBGP logs a warning: the received Update message was treated as withdraw. Code Path: The message reaches github.com/osrg/gobgp/v4/pkg/server.(peer).handleUpdate. Due to the malformed attributes, the message…
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An out-of-bounds read in the ParseIP6Extended function (/bgp/bgp.go) of gobgp v4.3.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted BGP UPDATE message.
Recommended action: Upgrade to 4.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability was determined in osrg GoBGP up to 4.3.0. Affected by this vulnerability is the function parseRibEntry of the file pkg/packet/mrt/mrt.go. Executing a manipulation can lead to integer underflow. It is possible to launch the attack remotely. Upgrading to version 4.4.0 addresses this issue. This patch is called 76d911046344a3923cbe573364197aa081944592. It is suggested to upgrade the affected component.
Recommended action: Upgrade to 4.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability has been found in osrg GoBGP up to 4.3.0. This impacts the function SRv6L3ServiceAttribute.DecodeFromBytes of the file pkg/packet/bgp/prefixsid.go of the component SRv6 L3 Service. Such manipulation of the argument data leads to denial of service. The attack may be performed from remote. Upgrading to version 4.4.0 will fix this issue. The name of the patch is f9f7b55ec258e514be0264871fa645a2c3edad11. Users should upgrade the affected component.
Recommended action: Upgrade to 4.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A remote Denial of Service (DoS) vulnerability exists in GoBGP where a malformed BGP UPDATE message can trigger a runtime error: index out of range panic. This occurs during the processing of 4-byte AS attributes when the message structure causes an internal slice index shift that is not properly handled. Details The vulnerability is located in internal/pkg/table/message.go within the UpdatePathAttrs4ByteAs function. When GoBGP processes a BGP UPDATE message containing both an ASPATH and an AS4PATH attribute, it attempts to merge or validate them to support 4-byte AS numbers. If the attributes are ordered such that AS4PATH (Type 17) appears before ASPATH (Type 2), and the AS4PATH is deemed invalid/malformed, the code attempts to remove the AS4PATH attribute from the msg.PathAttributes slice. It appears the crash happens due to an index shift in msg.PathAttributes: This deletion causes all subsequent attributes in the slice to shift left by one position. However, the function…
Recommended action: Upgrade to 4.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A remote Denial of Service (DoS) vulnerability exists in GoBGP due to a nil pointer dereference. When a malformed BGP UPDATE message contains an unrecognized Path Attribute marked as "Well-known," the daemon fails to interrupt the message handling flow. This results in an illegal memory access and a full process crash (panic). Details The vulnerability is located in the Finite State Machine (FSM) message handling loop in pkg/server/fsm.go. According to RFC 4271, any Path Attribute with the Optional bit set to 0 is treated as "Well-known." If the Type Code is unrecognized, the BGP speaker MUST send a NOTIFICATION message. In GoBGP v4.3.0, when such an attribute (e.g., Type 0xEE or 0xFF with flags 0x40) is received, the parsing layer identifies the error. However, the logic in recvMessageloop (around Line 1826) does not properly halt execution. It proceeds to reference the body of the parsed message. Because the message was deemed invalid during the initial attribute check, the…
Recommended action: Upgrade to 4.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue in GoBGP gobgpd v.4.2.0 allows a remote attacker to cause a denial of service via the NEXTHOP path attribute.
Recommended action: Upgrade to 4.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.