Helm 2's Tiller component solved a real problem — running chart operations from inside the cluster — by creating a much bigger one: a gRPC service with no authentication in front of it. CVE-2019-18658 documents exactly that weakness. Tiller listened on its gRPC port with no built-in check on who was calling it, which meant that anyone who could reach that port on the network — a compromised pod, a misconfigured NodePort or LoadBalancer Service, a workload on a shared node, or in the worst cases an internet-exposed cluster — could issue Tiller commands with whatever Kubernetes privileges Tiller itself held. Because Tiller was routinely deployed with cluster-admin-equivalent RBAC so it could manage resources across namespaces, that gap translated an ordinary network foothold into full cluster compromise: install, upgrade, or delete any release; read Secrets embedded in chart values; and pivot into workloads across every namespace Tiller could touch.
CVE-2019-18658 in Context: What Tiller Was and Why the Endpoint Mattered
Helm 2's architecture split the tool in two: the helm CLI ran on an operator's workstation, and Tiller ran server-side, inside the Kubernetes cluster, as the component that actually talked to the Kubernetes API to render and apply chart manifests. Client and server communicated over gRPC. The intended trust boundary was the Kubernetes API server itself — Helm's model assumed that if you couldn't reach the Tiller pod, you couldn't issue commands to it, and that anyone with kubectl exec/port-forward access to the cluster was already implicitly trusted.
That assumption broke down constantly in real-world deployments. Tiller's Service was frequently exposed more broadly than intended — through a NodePort, a LoadBalancer, permissive network policies (or the absence of any), or shared-cluster environments where workloads from different teams or tenants sat on the same network. In any of those situations, the unauthenticated gRPC endpoint meant no credential, token, or client certificate was required to talk to Tiller and ask it to do things on your behalf. Security researchers had flagged this class of risk in Helm 2 informally for a couple of years before it was catalogued as CVE-2019-18658, and it became one of the most cited reasons Kubernetes shops treated "is Tiller reachable from outside the cluster" as a standing audit item.
Affected Versions and Components
CVE-2019-18658 applies to Helm 2 deployments running Tiller, which NVD documents as affecting Helm through 2.14.3 — that is, the Helm 2.x release line as shipped, prior to the project moving away from the Tiller architecture altogether. The vulnerable component is Tiller's gRPC listener (default port 44134), not the helm client binary itself. Any cluster running Helm 2 with a default Tiller install, and any downstream tooling or CI/CD pipeline that provisioned Tiller with broad RBAC and left its Service reachable beyond the cluster's internal pod network, falls into the affected population. Helm 3, released in November 2019, removed Tiller entirely — the client talks directly to the Kubernetes API using the user's own credentials — which structurally eliminates this vulnerability class rather than patching around it.
Severity: CVSS, EPSS, and KEV Context
NVD's scoring reflects the low bar to exploitation and the high ceiling on impact: no authentication is required, no user interaction is needed, and a successful request against Tiller can affect the confidentiality, integrity, and availability of every resource Tiller is authorized to manage — which in a typical default install was the entire cluster. That combination is why the CVSS v3 base score sits in the high-severity band (commonly reported around 8.1). As of this writing, CVE-2019-18658 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and there isn't a widely tracked EPSS score reflecting active mass-exploitation — the risk here has always been driven less by a wormable exploit chain and more by how frequently the vulnerable configuration turned up in the wild. Multiple internet-scanning research efforts over the years found publicly reachable Tiller endpoints on Shodan-indexed hosts, which is the practical reason this issue kept resurfacing in Kubernetes hardening guides long after Helm 3 shipped.
Timeline
Concerns about Tiller's unauthenticated gRPC access model circulated in the Kubernetes and Helm community well before a CVE was assigned, largely as "hardening advice" rather than a formal advisory — restrict Tiller's Service, enable TLS, or scope its RBAC tightly. Helm 3, which removed Tiller as an architectural decision rather than a targeted fix, reached general availability in November 2019, the same window in which CVE-2019-18658 was published to formally catalogue the underlying weakness in Helm 2. The Helm project subsequently set a defined end-of-life date for Helm 2, giving teams a runway to migrate before Helm 2 stopped receiving security support altogether. For clusters still running Helm 2 today, there is no further upstream patch coming — Tiller is out of support, and the only durable remediation path is migration.
Remediation Steps
Because CVE-2019-18658 is a design flaw in a now end-of-life component rather than a single fixable code defect, remediation is really a hierarchy of mitigations that converge on one outcome: get Tiller out of the picture.
- Migrate to Helm 3. This is the actual fix. Helm 3 removes Tiller entirely, so there is no in-cluster gRPC listener to secure or expose in the first place. Helm provides a
2to3plugin to convert existing Helm 2 releases and configuration, and most charts from that era are compatible with minimal changes. - If you cannot migrate immediately, lock Tiller down hard. Enable Tiller's built-in TLS support so gRPC connections require mutually authenticated client certificates — this was always available but was not the default, which is precisely what made the unauthenticated posture the common case.
- Restrict network reachability. Apply Kubernetes NetworkPolicies so only the namespaces and workloads that legitimately need to reach Tiller's pod and Service can do so, and audit every Tiller Service for accidental
NodePortorLoadBalancerexposure. - Scope Tiller's RBAC. Avoid granting Tiller cluster-admin by default. Bind it to the narrowest ClusterRole or per-namespace Role that your deployment workflow actually requires, so that a compromised endpoint has a smaller blast radius.
- Audit for exposure now. Enumerate every cluster in your environment — including forgotten dev/test clusters — for a running Tiller pod and check whether its Service or port is reachable from outside the intended trust boundary. Given how long this configuration lingers unnoticed, this is worth treating as a recurring check, not a one-time sweep.
- Track it as end-of-life risk, not just a CVE. Helm 2 and Tiller are no longer maintained, so any Helm 2 installation carries open-ended risk beyond CVE-2019-18658 itself. Migration should be prioritized on that basis even where Tiller happens to be network-isolated today.
How Safeguard Helps
Legacy infrastructure components like an unpatched Helm 2/Tiller install are exactly the kind of risk that hides in plain sight — technically documented, well understood by the security community, and still present in production because nobody re-checked it after the initial rollout. Safeguard's software supply chain security platform is built to catch that gap. Continuous SBOM and dependency inventory scanning surfaces Helm 2 and Tiller wherever they still exist across your fleet, including clusters that predate your current tooling or ownership records, and maps them directly to known CVEs like CVE-2019-18658 rather than leaving that correlation to a spreadsheet.
Beyond detection, Safeguard's policy engine can flag end-of-life components such as Tiller for mandatory remediation timelines, verify that Kubernetes workloads and their deployment tooling meet your organization's hardening baselines, and give security and platform teams a single view of exposure across every cluster rather than one audit at a time. For a vulnerability class defined by "we forgot this was still running," that continuous, automated visibility is the difference between finding an exposed gRPC endpoint through your own scanning and finding it because someone else did first.