Akamai security researcher Tomer Peled has identified CVE-2024-9042: a remote code execution vulnerability that grants SYSTEM privileges on every Windows node in a Kubernetes cluster. The flaw, responsibly disclosed on June 28, 2024, exploits the beta Log Query feature and is triggered by a simple GET request — no YAML manifests or control-plane compromise required. The discovery raises fresh questions about user-input validation in Kubernetes' Windows-specific code, a path the same researcher previously explored with CVE-2023-3676.
- CVE-2024-9042 enables RCE with SYSTEM privileges on all Windows nodes in a Kubernetes cluster via command injection in the "pattern" parameter of the beta Log Query feature.
- Exploitation requires a single authenticated GET request to the target node's API; the source provides a proof-of-concept curl command that executes arbitrary code without interacting with the kube-apiserver.
- The root cause lies in the dynamic construction of PowerShell commands: the "pattern" input is concatenated directly into the
Where-Object -Property Message -Matchclause without sanitization, while only the service name undergoes regex validation. - Affected versions precede 1.32.1 and require the cluster to have opted into beta features; the most reliably tested environment combines Calico as CNI and NSSM for Windows service management.
How the Injection Works in Kubernetes Log Query
The Log Query feature, introduced as beta in Kubernetes, allows querying service logs on Windows nodes through the kubelet API. According to Akamai's analysis, the kubelet component dynamically builds a PowerShell command to filter log entries: the user supplies two parameters, "query" for the service name and "pattern" for the search criterion.
Validation, however, is asymmetric. The service name is checked with a regular expression. The "pattern" parameter receives only a length check: user input is concatenated directly into the Where-Object -Property Message -Match string without any transformation into a string literal. This allows breaking PowerShell syntax with a well-placed apostrophe and injecting arbitrary commands.
The vulnerable path is not universal. The source states that exploitation requires the target service to write logs via ETW (Event Tracing for Windows), not through klog. The researcher identified Calico with NSSM as a configuration that meets this condition: NSSM manages log output independently, bypassing Kubernetes mechanisms and guaranteeing direct writes to ETW. This makes the test environment particularly favorable, though the source does not rule out that other Windows setups may present similar prerequisites.
From a curl Request to SYSTEM: Akamai's Demonstration
The source explicitly provides the proof-of-concept: a curl request to the target node's proxy endpoint, with the pattern parameter crafted to execute an arbitrary process. The server response contains the output of the injected command, confirming execution with the kubelet service's privileges — SYSTEM on Windows.
The difference from previous vectors is substantial. CVE-2023-3676, discovered by the same Tomer Peled in 2023, required submitting a malformed YAML manifest to the kube-apiserver. CVE-2024-9042 eliminates that step: the attacker interacts directly with the node, reducing detection surface and control-plane oversight. To an operator monitoring traffic to the kube-apiserver, this GET request to the node proxy can appear as legitimate management traffic.
"The vulnerability allows remote code execution (RCE) with SYSTEM privileges on all Windows endpoints within a Kubernetes cluster" — Akamai Security Research
Why This Matters
The dossier does not specify the number of potentially affected clusters, nor does it document in-the-wild exploitation. The source indicates no remediation measures beyond upgrading to version 1.32.1, and does not detail whether Windows configurations other than Calico/NSSM present analogous ETW conditions.
The significance of the finding extends beyond a single CVE. This is the second time in two years that the same researcher has identified a systemic pattern: Windows-specific Kubernetes components that insert user input into PowerShell commands without adequate sanitization. The recurrence raises questions about code review practices for the Windows platform in the project, an area traditionally less scrutinized than the Linux path.
Hybrid Windows/Linux clusters are common in enterprise environments, especially for legacy workloads migrating to containers and cloud orchestration. The combination of Windows nodes with beta features enabled — typical during adoption of new logging capabilities — widens the exposure window compared to conservative installations. The simplicity of the GET vector further lowers the technical barrier for exploitation compared to attacks requiring deep understanding of Kubernetes' object model.
The source does not clarify whether the fix introduces additional controls on other Log Query parameters or if mitigation is scoped solely to "pattern." The dossier also does not document the exact release date of version 1.32.1, noting only that prior builds are affected.
The Fix and Disclosure Context
Kubernetes adopted a specific mitigation: the introduction of the kubelet_pattern environment variable, which treats the input as a string literal before passing it to the PowerShell command. This approach, documented by the source, eliminates the possibility of syntactic injection without altering log-filtering logic.
The disclosure timeline is partially known: on June 28, 2024, the researcher reported the issue to the Kubernetes security team; on July 18, 2024, a response was received, but the provided text truncates at "Kubernetes t." The source does not complete this detail.
Testing was conducted on both on-premise deployments and Azure Kubernetes Service, indicating the vulnerability is not conditioned by a specific cloud distribution but by the Windows subsystem and cluster configuration choices.
Frequently Asked Questions
Are Linux nodes affected?
No. The source explicitly states the vulnerability affects only Windows nodes in the cluster, as the vulnerable path uses PowerShell for log querying.
Must something be enabled to be at risk?
Yes. The Log Query feature is in beta and requires opt-in via the feature gate. Default installations that have not enabled beta features do not expose the vulnerable path.
Is the fix sufficient to protect other similar components?
The dossier provides no basis to evaluate whether the same dynamic PowerShell command construction exists in other Windows functionalities of Kubernetes. The source limits its documentation to the Log Query case.
Information is based on the cited advisory and current as of publication.
Sources
- https://www.akamai.com/blog/security-research/kubernetes-log-query-rce-windows
- https://www.akamai.com/blog
- https://www.akamai.com/blog/security-research