CVE-2026-55996: Rancher TLS Listener DoS Vulnerability

CVE-2026-55996 Overview

CVE-2026-55996 is a denial-of-service vulnerability affecting TLS listeners in Rancher. The flaw resides in the dynamiclistener library used by both the cattle-cluster-agent component in downstream clusters and the Rancher server itself. When no effective Common Name (CN) filter is configured, dynamiclistener appends any hostname received via Server Name Indication (SNI) to the serving certificate's Subject Alternative Names (SANs). An unauthenticated attacker with network access to the cluster can send crafted TLS requests with distinct hostnames to grow the certificate indefinitely. The condition is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling].

Critical Impact
Attackers with network access can exhaust Rancher TLS listener availability by forcing unbounded SAN growth until handshakes fail with excessive message size errors.

Affected Products

Rancher server (versions using the vulnerable dynamiclistener library)
cattle-cluster-agent component in downstream Kubernetes clusters
Deployments without an effective CN filter configured for dynamiclistener

Discovery Timeline

2026-08-05 - CVE-2026-55996 published to NVD
2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-55996

Vulnerability Analysis

Rancher relies on the dynamiclistener library to manage TLS certificates dynamically for its API server and cluster agents. The library inspects the SNI extension in incoming TLS ClientHello messages and adds the presented hostname to the certificate's SAN list when it is not already present. This behavior is intended to simplify certificate management across dynamic hostnames in Kubernetes environments.

Without a restrictive CN filter, dynamiclistener accepts arbitrary SNI values. Every unique hostname triggers a certificate regeneration that grows the SAN field. Over time, the certificate exceeds the maximum TLS message size, and every subsequent handshake fails. The listener becomes unreachable to legitimate clients until the certificate is manually rotated or the process restarts.

Root Cause

The root cause is unbounded resource allocation in the certificate generation logic. The library trusts attacker-controlled SNI values as valid hostnames to be pinned into the serving certificate. There is no upper bound on the number of SAN entries, no rate limiting on regeneration, and no default CN allow-list enforcement.

Attack Vector

The attacker requires network access to the affected TLS listener but does not need authentication credentials to the Rancher API. The attacker opens repeated TLS connections, each specifying a unique SNI hostname such as a1.example, a2.example, and so on. Each connection causes dynamiclistener to append the new hostname to the serving certificate. After a sufficient number of unique SNI values, the certificate's serialized form exceeds the 16 KB TLS record ceiling, and the listener returns a handshake failure due to excessive message size.

No verified public exploit code is available. See the GitHub Security Advisory GHSA-9jxv-832x-45q9 and the SUSE Bug Report CVE-2026-55996 for authoritative technical details.

Detection Methods for CVE-2026-55996

Indicators of Compromise

Rancher server or cattle-cluster-agent logs reporting TLS handshake failures with tls: server sent handshake with excessive message size or similar errors.
Repeated TLS ClientHello messages from the same source addresses containing distinct, non-existent hostnames in the SNI field.
Rapid growth in the SAN list of the serving certificate returned by the Rancher API endpoint.

Detection Strategies

Monitor certificate churn on Rancher endpoints by periodically fetching the serving certificate and counting SAN entries over time.
Inspect load balancer or ingress logs for high-cardinality SNI values directed at Rancher management endpoints.
Alert on TLS handshake error rates exceeding baseline thresholds for the Rancher server and downstream agents.

Monitoring Recommendations

Enable audit logging in dynamiclistener and forward events to a central SIEM for correlation with source IPs.
Track the size and SAN count of Rancher serving certificates as a metric in Prometheus or an equivalent observability stack.
Baseline expected client hostnames used to reach Rancher and alert when SNI values fall outside the allow-list.

How to Mitigate CVE-2026-55996

Immediate Actions Required

Upgrade Rancher and the cattle-cluster-agent to a patched release as indicated in the GitHub Security Advisory GHSA-9jxv-832x-45q9.
Configure an explicit CN filter in dynamiclistener so that only trusted hostnames can be appended to the serving certificate.
Restrict network exposure of Rancher TLS listeners to trusted management networks using firewall rules or Kubernetes NetworkPolicy.

Patch Information

Refer to the GitHub Security Advisory GHSA-9jxv-832x-45q9 for the fixed versions of Rancher and updated dynamiclistener releases. SUSE tracks the same defect in the SUSE Bug Report CVE-2026-55996, which lists downstream package updates. Apply patched releases to both the Rancher server and every downstream cluster running the cattle-cluster-agent.

Workarounds

Place a hardened reverse proxy in front of Rancher that terminates TLS and validates SNI against an allow-list before forwarding.
Use NetworkPolicy or equivalent controls to permit connections to Rancher listeners only from authorized management CIDRs.
Periodically restart affected Rancher components or rotate serving certificates until patched builds are deployed.

bash

# Configuration example - restrict Rancher TLS access via NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-rancher-tls
  namespace: cattle-system
spec:
  podSelector:
    matchLabels:
      app: rancher
  policyTypes:
    - Ingress
  ingress:
    - from:
        - ipBlock:
            cidr: 10.0.0.0/8
      ports:
        - protocol: TCP
          port: 443