What is the CVSS score of CVE-2026-49837?

CVE-2026-49837 has a CVSS 3.1 base score of 5.9 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N. EPSS exploitation probability: 0.3%.

Is there a public PoC exploit available for CVE-2026-49837?

Yes, a public proof-of-concept exploit is available for CVE-2026-49837. Prioritise patching immediately. EPSS: 0.3%.

Is there a patch available for CVE-2026-49837?

Yes, a patch is available for CVE-2026-49837. Update the affected software to the latest version immediately.

GoBGP CVE-2026-49837

MEDIUM

Out-of-bounds Read (CWE-125)

2026-07-09 https://github.com/osrg/gobgp

GHSA-gjrg-jjr3-56cm

RCE Buffer Overflow Information Disclosure

5.9

CVSS 3.1 · Vendor: https://github.com/osrg/gobgp

Severity by source

Vendor (https://github.com/osrg/gobgp) PRIMARY

5.9 MEDIUM

AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

vuln.today AI

5.9 MEDIUM

AV:N for network-delivered BGP OPEN; AC:H because attacker must reach TCP/179 in a typically restricted peer environment; I:H for AS validation manipulation; C:N and A:N per explicit vendor exclusion of those impact classes.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

SUSE

MEDIUM

qualitative

Primary rating from Vendor (https://github.com/osrg/gobgp).

CVSS VectorVendor: https://github.com/osrg/gobgp

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Generated

Jul 09, 2026 - 23:56 vuln.today

DescriptionCVE.org

Summary

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 versions, the generic capability parser records the declared CapLen, but several concrete capability decoders continue parsing from the full remaining capability buffer after advancing past the two-byte capability header. Conceptually, the vulnerable pattern is:

data = data[2:]
// decoder reads from data without first limiting it to CapLen
### PoC
The following parser-level proof of concept demonstrates the issue without requiring a full BGP session or a running `bgpd` instance.
The malformed capability uses:
- Capability Code: `65` (`BGP_CAP_FOUR_OCTET_AS_NUMBER`)
- Declared `CapLen`: `0`
- Four following bytes: `00 00 fd e8`

Although the capability declares an empty value, affected versions parse the following four bytes as the 4-octet AS value `65000`.
### Impact
A remote peer that can send a malformed BGP OPEN message to a GoBGP instance may cause capability values to be parsed from outside their declared `CapLen` boundaries.
In the 4-octet AS capability case, this may affect:
- peer AS validation;
- capability negotiation;
- interpretation of malformed OPEN messages;
- acceptance or rejection decisions during BGP session establishment.
This issue does not appear to be arbitrary memory corruption, remote code execution, or information disclosure. It is a protocol parser boundary validation issue that can affect BGP OPEN validation semantics.

AnalysisAI

Boundary validation failure in GoBGP's BGP OPEN capability parser allows a remote peer to send a malformed OPEN message that causes concrete capability decoders to read beyond the declared CapLen field, enabling attacker-controlled bytes to be interpreted as capability values - most critically, as a 4-octet AS number that influences peer AS validation and BGP session establishment decisions. Affected is GoBGP v4 (pkg:go/github.com_osrg_gobgp_v4), with the 4-octet AS capability (code 65) identified as the highest-impact case. A parser-level proof-of-concept is publicly described in GitHub Security Advisory GHSA-gjrg-jjr3-56cm; no active exploitation has been confirmed and this CVE does not appear in the CISA KEV catalog. IMPORTANT METADATA CONFLICT: The provided intelligence tags label this as 'RCE, Buffer Overflow, Information Disclosure' - all three directly contradict the CVE description, which explicitly states the issue is not arbitrary memory corruption, remote code execution, or information disclosure; security teams must disregard those tags.

Technical ContextAI

GoBGP is an open-source BGP (Border Gateway Protocol) daemon and library written in Go, identified by package reference pkg:go/github.com_osrg_gobgp_v4. The vulnerability is rooted in CWE-125 (Out-of-bounds Read) and resides in the capability parsing logic within pkg/packet/bgp/bgp.go and pkg/packet/bgp/validate.go. BGP OPEN messages carry optional parameters containing capabilities, each encoded as a three-part structure: a capability code byte, a capability length byte (CapLen), and a value field of exactly CapLen bytes. The vulnerable pattern occurs because the generic parser correctly records CapLen but then advances the data slice past only the two-byte header before handing it to concrete capability decoders; those decoders then read from the full remaining buffer rather than from a sub-slice limited to CapLen. In Go, this does not produce a panic or true memory corruption because slice bounds are enforced by the runtime, but it does allow bytes belonging to the next capability in the buffer to be parsed as if they were part of the current capability's value. The 4-octet AS number capability (code 65, RFC 6793) is the most security-relevant case: a CapLen of 0 with four following bytes causes those bytes to be parsed as the AS number, which may then influence peer AS validation during session establishment.

RemediationAI

Consult the GitHub Security Advisory GHSA-gjrg-jjr3-56cm at https://github.com/osrg/gobgp/security/advisories/GHSA-gjrg-jjr3-56cm for the authoritative fixed release version; no specific patched version number was confirmed in the available intelligence data, so the upstream fix should be treated as 'available per vendor advisory - released version not independently confirmed.' As a compensating control while awaiting a patched release, restrict inbound TCP access to port 179 on GoBGP instances to only explicitly configured, trusted peer IP addresses using host-based or perimeter firewall rules - this directly limits who can deliver a malformed OPEN message, though it does not eliminate risk if a trusted peer is itself compromised. Where supported by the deployment environment, enabling TCP MD5 session authentication for BGP peering sessions adds an additional layer that requires the attacker to know the session secret. Operators should also audit BGP session logs for unexpected AS number negotiation values as an indicator of attempted exploitation.