Vulnerabilities in pkg:golang/github.com/cloudnativelabs/kube-router/v2

PACKAGE
Advisory Summary

GHSA-fcmh-qfxc-w685 is a MODERATE (CVSS 4.1) bgp peer passwords exposed vulnerability (CWE-532: Insertion of Sensitive Information into Log File) affecting kube-router libraries in the Go ecosystem. The issue involves bgp peer passwords exposed in logs at verbose logging level. Remediation is available in the latest vendor maintenance releases.

2 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:golang/github.com/cloudnativelabs/kube-router/v2

2 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:golang/github.com/cloudnativelabs/kube-router/v2. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-fcmh-qfxc-w685 - MODERATE kube-router: BGP Peer Passwords Exposed in Logs at Verbose Logging Level
GHSA-phqm-jgc3-qf8g CVE-2026-32254 HIGH Kube-router Proxy Module Blindly Trusts ExternalIPs/LoadBalancer IPs Enabling Cluster-Wide Traffic Hijacking and DNS DoS

GHSA-fcmh-qfxc-w685 at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-fcmh-qfxc-w685
Severity MODERATE
CVSS v3.1 Base Score 4.1
CWE Classification CWE-532: Insertion of Sensitive Information into Log File
Affected Product kube-router
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 4.1

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N).

Attack Vector Local (AV:L)
Attack Complexity High (AC:H)
Privileges Required High (PR:H)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity None (I:N)
Availability None (A:N)

How to Fix GHSA-fcmh-qfxc-w685

To remediate this vulnerability, upgrade all affected kube-router dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/cloudnativelabs/kube-router/v2 fixed: Latest secure release
Upgrade github.com/cloudnativelabs/kube-router/v2 to Latest secure release
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/cloudnativelabs/kube-router/v2

How to Check if You Are Affected

To determine whether your application is affected by GHSA-fcmh-qfxc-w685, inspect your project dependencies for kube-router:

inspect dependencies for github.com/cloudnativelabs/kube-router/v2

Analyze the terminal output to locate any version of kube-router in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than the patched release), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-532: Insertion of Sensitive Information into Log File, where the product writes sensitive information to a log file. In kube-router, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary When kube-router is configured with per-node BGP peer passwords using the `kube-router.io/peer.passwords` node annotation, and verbose logging is enabled (`--v=2` or higher), the raw Kubernetes node annotation map is logged verbatim — including the base64-encoded BGP MD5 passwords. Anyone with access to kube-router's logs (via `kubectl logs`, log aggregation systems, or shared log dumps during debugging) can extract and decode the BGP peer passwords. The official troubleshooting documentation instructs users to collect logs at `-v=2` before filing issues, making accidental disclosure during support interactions a realistic scenario. ## Details The vulnerability is at `pkg/controllers/routing/network_routes_controller.go:1129`: ```go // pkg/controllers/routing/network_routes_controller.go:1127-1133 // If the global routing peer is configured then peer with it // else attempt to get peers from node specific BGP annotations. if len(nrc.globalPeerRouters) == 0 { klog.V(2).Infof("Attempting to construct peer configs from annotation: %+v", node.Annotations) peerCfgs, err := bgpPeerConfigsFromAnnotations( ``` `node.Annotations` is of type `map[string]string`. This type does not implement `fmt.Stringer`, so `%+v` formatting dumps every key-value pair verbatim. When `kube-router.io/peer.passwords` is set on the node (the documented mechanism for providing per-node BGP MD5 passwords), its base64-encoded value appears in the log output. The BGP peer password annotation is documented in `docs/user-guide.md` and has the constant: ```go // pkg/controllers/routing/network_routes_controller.go:59 peerPasswordAnnotation = "kube-router.io/peer.passwords" ``` Note that a password-safe `String()` method exists on `PeerConfig` and `PeerConfigs` in `pkg/bgp/peer_config.go` and is tested: ```go // pkg/bgp/peer_config.go:63-79 // Custom Stringer to prevent leaking passwords when printed func (p PeerConfig) String() string { // ...password field is intentionally omitted... } ``` However, this protective method is never invoked by the vulnerable log statement, which dumps the raw annotation map before any parsing occurs. The password masking only applies after the annotation is parsed into `PeerConfig` structs. The second log statement at line 1510 (`klog.Infof("Peer config from %s annotation: %+v", peersAnnotation, peerConfigs)`) is **not vulnerable** — `peerConfigs` is of type `bgp.PeerConfigs` which implements `fmt.Stringer` and correctly masks passwords. The vulnerable path (`bgpPeerConfigsFromIndividualAnnotations`) is triggered when the `kube-router.io/peers` consolidated YAML annotation is not set — i.e., when operators use the older individual annotation format (`kube-router.io/peer.ips`, `kube-router.io/peer.asns`, `kube-router.io/peer.passwords`). This older format remains fully supported and documented. ## PoC **Setup**: Node has per-node BGP peer annotations including a password: ```bash kubectl annotate node worker-1 \ kube-router.io/peer.ips=192.0.2.1 \ kube-router.io/peer.asns=65001 \ "kube-router.io/peer.passwords=$(echo -n 's3cr3t-bgp-p@ss' | base64)" ``` **Trigger**: Start kube-router with verbose logging (e.g., following troubleshooting documentation): ```bash # As documented in docs/troubleshoot.md for debugging: kube-router ... --v=2 ``` **Observe**: In kube-router pod logs: ``` I0318 10:23:41.123456 1 network_routes_controller.go:1129] Attempting to construct peer configs from annotation: map[ kube-router.io/peer.asns:65001 kube-router.io/peer.ips:192.0.2.1 kube-router.io/peer.passwords:czNjcjN0LWJncC1wQHNz <-- base64-encoded password ...other annotations... ] ``` **Decode the password**: ```bash echo "czNjcjN0LWJncC1wQHNz" | base64 -d # Output: s3cr3t-bgp-p@ss ``` **Impact**: With the decoded password and network adjacency to the BGP peer, an attacker can establish an unauthorized BGP session, inject routes, or disrupt legitimate BGP peering. ## Impact - **BGP credential disclosure**: BGP MD5 authentication passwords are exposed to anyone with access to kube-router log output - **BGP session hijacking**: An attacker who obtains the password and has network-level access to a BGP neighbor can impersonate the kube-router node, injecting malicious routes into the BGP table - **Log forwarding risk**: Log aggregation systems (Fluentd, Loki, Elastic, Splunk) typically have different and often broader access controls than Kubernetes RBAC. Passwords aggregated into these systems may be accessible to personnel without Kubernetes node access - **Support workflow exposure**: The official troubleshooting documentation recommends collecting `--v=2` logs before filing issues, creating a realistic path for passwords to be shared in bug reports or support tickets ## Recommended Fix Remove or redact the vulnerable log statement at line 1129. The diagnostic information it provides (confirming that annotation-based peer configuration is being used) can be conveyed without exposing credential values: ```go // Before (vulnerable): klog.V(2).Infof("Attempting to construct peer configs from annotation: %+v", node.Annotations) // After (safe): klog.V(2).Infof("Attempting to construct peer configs from per-node annotations (kube-router.io/peer.ips, etc.)") ``` If full annotation content is needed for debugging (e.g., to show non-sensitive annotations), log a filtered version that explicitly excludes the password annotation: ```go // Safe alternative that preserves non-sensitive diagnostic info: safeAnnotations := make(map[string]string) for k, v := range node.Annotations { if k != peerPasswordAnnotation { safeAnnotations[k] = v } } klog.V(2).Infof("Attempting to construct peer configs from annotations: %+v", safeAnnotations) ```

GHSA-fcmh-qfxc-w685 Affected kube-router Versions

1 component(s)
Product / Package Ecosystem Affected Versions Fixed Version
github.com/cloudnativelabs/kube-router/v2
Go
≥ 2.7.0
≤ 2.8.0

References

Frequently Asked Questions

What is GHSA-fcmh-qfxc-w685?
GHSA-fcmh-qfxc-w685 is a security vulnerability in kube-router involving BGP Peer Passwords Exposed in Logs at Verbose Logging Level under CWE-532: Insertion of Sensitive Information into Log File.
Which kube-router versions are affected?
Affected versions include releases prior to current release patches across affected packages: github.com/cloudnativelabs/kube-router/v2.
What version fixes GHSA-fcmh-qfxc-w685?
Upgrading to current release patches (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/cloudnativelabs/kube-router/v2 affected?
Yes, github.com/cloudnativelabs/kube-router/v2 is affected in releases prior to Latest secure release. Upgrade your dependency to Latest secure release or later.
What is the CVSS score of GHSA-fcmh-qfxc-w685?
GHSA-fcmh-qfxc-w685 has a CVSS v3.1 base score of 4.1 (MODERATE) with vector string CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N.
What CWE is associated with GHSA-fcmh-qfxc-w685?
GHSA-fcmh-qfxc-w685 is classified under CWE-532: Insertion of Sensitive Information into Log File (The product writes sensitive information to a log file.).
How can I check Go dependencies for GHSA-fcmh-qfxc-w685?
Run the dependency tree command: 'inspect dependencies for github.com/cloudnativelabs/kube-router/v2'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-fcmh-qfxc-w685",
  "modified" : "2026-04-08T00:07:53Z",
  "published" : "2026-04-08T00:07:53Z",
  "aliases" : [ ],
  "summary" : "kube-router: BGP Peer Passwords Exposed in Logs at Verbose Logging Level",
  "details" : "## Summary\n\nWhen kube-router is configured with per-node BGP peer passwords using the `kube-router.io/peer.passwords` node annotation, and verbose logging is enabled (`--v=2` or higher), the raw Kubernetes node annotation map is logged verbatim — including the base64-encoded BGP MD5 passwords. Anyone with access to kube-router's logs (via `kubectl logs`, log aggregation systems, or shared log dumps during debugging) can extract and decode the BGP peer passwords. The official troubleshooting documentation instructs users to collect logs at `-v=2` before filing issues, making accidental disclosure during support interactions a realistic scenario.\n\n## Details\n\nThe vulnerability is at `pkg/controllers/routing/network_routes_controller.go:1129`:\n\n```go\n// pkg/controllers/routing/network_routes_controller.go:1127-1133\n// If the global routing peer is configured then peer with it\n// else attempt to get peers from node specific BGP annotations.\nif len(nrc.globalPeerRouters) == 0 {\n    klog.V(2).Infof(\"Attempting to construct peer configs from annotation: %+v\", node.Annotations)\n    peerCfgs, err := bgpPeerConfigsFromAnnotations(\n```\n\n`node.Annotations` is of type `map[string]string`. This type does not implement `fmt.Stringer`, so `%+v` formatting dumps every key-value pair verbatim. When `kube-router.io/peer.passwords` is set on the node (the documented mechanism for providing per-node BGP MD5 passwords), its base64-encoded value appears in the log output.\n\nThe BGP peer password annotation is documented in `docs/user-guide.md` and has the constant:\n\n```go\n// pkg/controllers/routing/network_routes_controller.go:59\npeerPasswordAnnotation = \"kube-router.io/peer.passwords\"\n```\n\nNote that a password-safe `String()` method exists on `PeerConfig` and `PeerConfigs` in `pkg/bgp/peer_config.go` and is tested:\n\n```go\n// pkg/bgp/peer_config.go:63-79\n// Custom Stringer to prevent leaking passwords when printed\nfunc (p PeerConfig) String() string {\n    // ...password field is intentionally omitted...\n}\n```\n\nHowever, this protective method is never invoked by the vulnerable log statement, which dumps the raw annotation map before any parsing occurs. The password masking only applies after the annotation is parsed into `PeerConfig` structs.\n\nThe second log statement at line 1510 (`klog.Infof(\"Peer config from %s annotation: %+v\", peersAnnotation, peerConfigs)`) is **not vulnerable** — `peerConfigs` is of type `bgp.PeerConfigs` which implements `fmt.Stringer` and correctly masks passwords.\n\nThe vulnerable path (`bgpPeerConfigsFromIndividualAnnotations`) is triggered when the `kube-router.io/peers` consolidated YAML annotation is not set — i.e., when operators use the older individual annotation format (`kube-router.io/peer.ips`, `kube-router.io/peer.asns`, `kube-router.io/peer.passwords`). This older format remains fully supported and documented.\n\n## PoC\n\n**Setup**: Node has per-node BGP peer annotations including a password:\n```bash\nkubectl annotate node worker-1 \\\n  kube-router.io/peer.ips=192.0.2.1 \\\n  kube-router.io/peer.asns=65001 \\\n  \"kube-router.io/peer.passwords=$(echo -n 's3cr3t-bgp-p@ss' | base64)\"\n```\n\n**Trigger**: Start kube-router with verbose logging (e.g., following troubleshooting documentation):\n```bash\n# As documented in docs/troubleshoot.md for debugging:\nkube-router ... --v=2\n```\n\n**Observe**: In kube-router pod logs:\n```\nI0318 10:23:41.123456 1 network_routes_controller.go:1129] Attempting to construct peer configs from annotation:\nmap[\n  kube-router.io/peer.asns:65001\n  kube-router.io/peer.ips:192.0.2.1\n  kube-router.io/peer.passwords:czNjcjN0LWJncC1wQHNz   <-- base64-encoded password\n  ...other annotations...\n]\n```\n\n**Decode the password**:\n```bash\necho \"czNjcjN0LWJncC1wQHNz\" | base64 -d\n# Output: s3cr3t-bgp-p@ss\n```\n\n**Impact**: With the decoded password and network adjacency to the BGP peer, an attacker can establish an unauthorized BGP session, inject routes, or disrupt legitimate BGP peering.\n\n## Impact\n\n- **BGP credential disclosure**: BGP MD5 authentication passwords are exposed to anyone with access to kube-router log output\n- **BGP session hijacking**: An attacker who obtains the password and has network-level access to a BGP neighbor can impersonate the kube-router node, injecting malicious routes into the BGP table\n- **Log forwarding risk**: Log aggregation systems (Fluentd, Loki, Elastic, Splunk) typically have different and often broader access controls than Kubernetes RBAC. Passwords aggregated into these systems may be accessible to personnel without Kubernetes node access\n- **Support workflow exposure**: The official troubleshooting documentation recommends collecting `--v=2` logs before filing issues, creating a realistic path for passwords to be shared in bug reports or support tickets\n\n## Recommended Fix\n\nRemove or redact the vulnerable log statement at line 1129. The diagnostic information it provides (confirming that annotation-based peer configuration is being used) can be conveyed without exposing credential values:\n\n```go\n// Before (vulnerable):\nklog.V(2).Infof(\"Attempting to construct peer configs from annotation: %+v\", node.Annotations)\n\n// After (safe):\nklog.V(2).Infof(\"Attempting to construct peer configs from per-node annotations (kube-router.io/peer.ips, etc.)\")\n```\n\nIf full annotation content is needed for debugging (e.g., to show non-sensitive annotations), log a filtered version that explicitly excludes the password annotation:\n\n```go\n// Safe alternative that preserves non-sensitive diagnostic info:\nsafeAnnotations := make(map[string]string)\nfor k, v := range node.Annotations {\n    if k != peerPasswordAnnotation {\n        safeAnnotations[k] = v\n    }\n}\nklog.V(2).Infof(\"Attempting to construct peer configs from annotations: %+v\", safeAnnotations)\n```",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/cloudnativelabs/kube-router/v2"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "2.7.0"
      }, {
        "last_affected" : "2.8.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/cloudnativelabs/kube-router/security/advisories/GHSA-fcmh-qfxc-w685"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/cloudnativelabs/kube-router"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-532" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-08T00:07:53Z",
    "nvd_published_at" : null
  }
}