Kubernetes Security Alert

A significant security vulnerability has been discovered in Kubernetes that allows attackers with seemingly read-only permissions to execute arbitrary commands across an entire cluster. The issue centers on the nodes/proxy GET permission, a commonly granted access right used by many monitoring and observability tools, that can be exploited to achieve full cluster compromise.

Despite the severity of the issue, the Kubernetes Security Team has classified this as ‘working as intended’ and will not issue a CVE. This decision has significant implications for organizations running Kubernetes in production environments.

 

What Is the Vulnerability?

The vulnerability exploits an inconsistency in how Kubernetes handles authorization for the Kubelet API. In standard Kubernetes RBAC (Role-Based Access Control), permissions are divided into ‘verbs’ that distinguish between read (GET) and write (CREATE) operations. This separation is fundamental to the principle of least privilege; monitoring tools should be able to read metrics without having the ability to execute commands.

However, security researcher Graham Helton discovered that the nodes/proxy GET permission, intended for read-only access to node metrics and logs, can be abused to execute commands in any Pod across the cluster. The root cause lies in how the Kubelet processes requests that use the WebSocket protocol.

How the Exploitation Works

When a client connects to the Kubelet’s /exec endpoint using WebSockets (required for interactive command execution), the initial handshake uses an HTTP GET request. The Kubelet makes its authorization decision solely based on this initial GET request, checking whether the user has nodes/proxy GET permissions. It never verifies whether the user has the CREATE permission required for command execution.

This means that any service account with nodes/proxy GET permission and network access to the Kubelet API (port 10250) can:

• Execute commands in any Pod on reachable nodes
• Target privileged system Pods to gain root access
• Access control plane components, including etcd and kube-apiserver
• Extract cluster secrets and sensitive data
• Operate without generating the usual audit logs for command execution

 

Why This Matters

Widespread Impact

The nodes/proxy GET permission is not exotic; it is routinely granted to monitoring and observability tools. Helton’s research identified 69 Helm charts from major vendors that use this permission, including:

• Prometheus (prometheus-community/prometheus)
• Grafana Promtail (grafana/promtail)
• Datadog (datadog/datadog)
• Elastic Agent (elastic/elastic-agent)
• OpenTelemetry (opentelemetry-helm/opentelemetry-kube-stack)
• Trivy Operator (trivy-operator/trivy-operator)
• New Relic (newrelic/newrelic-infrastructure)
• Cilium (cilium/cilium)
• Fluent Bit (fluent/fluent-bit)

Organizations using any of these tools may be exposed if an attacker can compromise the associated service account.

Stealth Factor

Commands executed through direct Kubelet API access do not traverse the Kubernetes API Server. This means that standard Kubernetes Audit Policies do not log the actual commands being executed; only the initial authorization check appears in audit logs. Attackers could establish persistent access or exfiltrate data without leaving obvious traces.

Multi-tenant Environments at Higher Risk

The vulnerability is particularly concerning for clusters that:

• Host multiple tenants or teams
• Treat node boundaries as security isolation
• Have service accounts accessible to workloads that shouldn’t have cluster-wide access

 

The Disclosure Timeline

Date	Event
November 1, 2025	Initial report submitted to Kubernetes Security Team
November 25, 2025	Report triaged
December 14, 2025	90-day disclosure timeline communicated
January 23, 2026	Kubernetes Security Team responds: Won’t Fix
January 26, 2026	Public disclosure by the researcher

 

Kubernetes Security Team Response

The Kubernetes Security Team acknowledged the behavior but declined to issue a fix, stating that the behavior is ‘working as intended.’ Their response highlighted that:

1. Fixing the issue would require architectural changes to both the Kubelet and API Server
2. The recommended path forward is KEP-2862 (Fine-Grained Kubelet API Authorization), expected to reach General Availability in Kubernetes 1.36 (April 2026)
3. KEP-2862 introduces specific subresource permissions as alternatives to the broad nodes/proxy permission

The Researcher’s Counterpoints

Helton raised several concerns with this response:

1. Inconsistent Fix Application: A similar issue affecting pods/exec was fixed in Kubernetes v1.35 by adding a secondary authorization check. The same pattern was not applied to the Kubelet.
2. KEP-2862 Limitations: The proposed solution does not provide alternatives for /exec, /run, /attach, or /portforward endpoints. Tools requiring these operations must still use nodes/proxy.
3. Documentation Mismatch: Kubernetes documentation states that “the kubelet authorizes API requests using the same request attributes approach as the apiserver,” but the behavior differs between the two paths.

Detection and Mitigation

Detecting Vulnerable Service Accounts

Administrators can use the researcher-provided detection script to identify service accounts with nodes/proxy permissions (Detection Script).

The script scans ClusterRoles and their bindings to identify potentially vulnerable service accounts. It is important to note that the script detects explicit grants and may not catch permissions inherited from wildcard roles or cluster-admin.

For comprehensive coverage, consider using tools like kubectl-who-can for deeper analysis.

Mitigation Strategies

While there is no official patch, organizations can reduce their risk through:

1. Network Segmentation: Restrict network access to the Kubelet API (port 10250). If workloads cannot reach this port, they cannot exploit the vulnerability.
2. Review RBAC Grants: Audit which service accounts have nodes/proxy permissions and assess whether they truly require this access.
3. Enable KEP-2862 (if available): For clusters running Kubernetes 1.34+, the Fine-Grained Kubelet Authorization feature can be enabled with the feature gate –feature-gates=KubeletFineGrainedAuthz=true. This provides more granular alternatives for read-only operations.
4. Monitor for Exploitation: While exploitation doesn’t generate standard audit logs for command execution, the subjectaccessreviews authorization checks are still logged. Unusual patterns in these logs may indicate exploitation attempts.
5. Vendor Coordination: Contact vendors whose monitoring tools require nodes/proxy permissions to understand their roadmap for adopting KEP-2862.

Recommendations for Kubernetes Users

Immediate Actions

• Inventory: Identify all service accounts in your clusters with nodes/proxy permissions
• Assess Network Exposure: Determine whether workloads can reach node IP addresses on port 10250
• Evaluate Risk: Consider whether your threat model includes compromised Pods with monitoring permissions

Long-term Planning

• Track KEP-2862: Monitor the progress of Fine-Grained Kubelet Authorization toward General Availability
• Update Tooling: As vendors adopt KEP-2862, plan to update Helm charts and monitoring configurations
• Defense in Depth: Treat this as a reminder that read-only permissions in Kubernetes may have unexpected capabilities

Conclusion

This vulnerability highlights a fundamental tension in Kubernetes security architecture. The nodes/proxy resource was designed as a convenience for accessing node-level data, but its broad scope creates unexpected attack paths. The researcher’s comparison to Kerberoasting in Active Directory is apt—some “working as intended” behaviors can have significant security implications that persist for years.

For organizations running Kubernetes, the practical advice is clear: audit your permissions, limit network access to the Kubelet API, and prepare to migrate to fine-grained permissions once they become generally available.

References

• Original Research Article: Kubernetes Remote Code Execution Via Nodes/Proxy GET Permission by Graham Helton
• Detection Script: detect-nodes-proxy.sh
• Interactive Lab: Nodes/Proxy RCE Lab
• KEP-2862: Fine-Grained Kubelet API Authorization
• Kubernetes RBAC Good Practices: Access to proxy subresource of Nodes
• Related Reading: When is read-only not read-only? by Rory McCune

Note: this article summarizes and contextualizes research originally published by Graham Helton. Yonder, as a Kubernetes-certified service provider (KCSP), can help organizations conduct security assessments tailored to their specific environments and threat models.

By Alex Coman,
Software Architect

Banner by Lianhao Qu on Unsplash