Loading story…
A high-severity flaw tracked as CVE-2026-61459 affects Flux159's mcp-server-kubernetes before version 3.9.0, allowing argument injection in the structured tools kubectl_get, kubectl_describe, and kubectl_delete. Attackers can supply resourceType or name values beginning with dashes to bypass the project's assertNoDangerousFlags check and inject flags such as --server, redirecting kubectl requests to an attacker-controlled Kubernetes API endpoint.
The redirection can cause the operator's bearer token to be transmitted externally and could lead to full Kubernetes cluster compromise. Flux159 addressed the issue in version 3.9.0 with a hardening patch that adds argv-wide validation through assertSafeArgv and a guarded execution wrapper, replacing direct command execution across affected kubectl and helm modules while also blocking dangerous kube-related flags that could alter API server or credential handling.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
3 events from the most recent confirmed update back to the earliest known activity.
Public advisories described CVE-2026-61459 as an argument injection vulnerability in mcp-server-kubernetes structured tools including kubectl_get, kubectl_describe, and kubectl_delete. The disclosures explained that attackers could bypass the existing dangerous-flag check with leading-dash parameters and redirect kubectl to an attacker-controlled API server.
References state that the argument injection vulnerability affecting mcp-server-kubernetes versions before 3.9.0 was addressed in the 3.9.0 release. The flaw allowed attackers to abuse structured kubectl tools by passing leading-dash parameters such as --server to exfiltrate bearer tokens and potentially compromise a cluster.
A GitHub commit introduced argv-wide validation and a guarded execFileSync wrapper to block dangerous kubectl and helm flags, mitigating argument injection that could redirect connections to an attacker-controlled Kubernetes API server or substitute credentials.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
5 references tracked. Mallory keeps watching after this page renders.
threataft.com
Open sourcecvefeed.io
Open sourcevulncheck.com
Open sourcegithub.com
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
JFrog Security Research disclosed four vulnerabilities in the Chaos Mesh chaos-engineering platform that can let attackers with in-cluster network access compromise Kubernetes environments, including three critical command-injection bugs and one authentication bypass. The issues, tracked as **CVE-2025-59358**, **CVE-2025-59359**, **CVE-2025-59360**, and **CVE-2025-59361**, affect Chaos Mesh deployments prior to **2.7.3** and stem from an exposed unauthenticated GraphQL server plus unsafe shell command construction in the `cleanTcs`, `killProcesses`, and `cleanIptables` mutations. JFrog said the default configuration can expose the GraphQL interface to any pod on the cluster, allowing even an unprivileged workload to reach vulnerable operations. Researchers reported that the flaws can be chained to invoke fault injections, execute arbitrary commands on pods and nodes, steal Kubernetes service account tokens, move laterally, and potentially take over an entire cluster. The command-injection bugs were rated **CVSS 9.8** and are especially dangerous because Chaos Mesh components such as the Controller Manager and Chaos Daemon typically run with elevated privileges. Chaos Mesh has issued fixes, including changes referenced in GitHub pull request **#4702**, and JFrog urged users to upgrade immediately to **Chaos Mesh 2.7.3** or disable the controller server through Helm as a temporary mitigation; platforms that integrate Chaos Mesh, including **Azure Chaos Studio for AKS**, may also be exposed.
Jun 29, 2026
Two high-severity vulnerabilities in the Kubernetes-native serverless platform **Fission** were disclosed, both allowing low-privileged tenants to inject unsafe `PodSpec` fields that can lead to **node escape** and broader **cluster compromise**. **CVE-2026-50563** affects the Container Executor path, where `Function.spec.podspec` could be merged into an executor-generated pod definition before a Deployment is created, while **CVE-2026-50545** affects the Environment CRD path through insufficient validation of `Environment.spec.runtime.podSpec` and `spec.builder.podSpec`. Both issues carry a CVSS v3.1 rating of `AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H`, reflecting low attack complexity and high impact to confidentiality, integrity, and availability. The flaws affect **Fission versions prior to 1.24.0**, and the project has released fixes in **version 1.24.0** alongside related GitHub advisories and pull requests. The disclosures indicate that unsafe passthrough and merge behavior in pod creation logic could let a tenant influence generated pods in ways that break isolation boundaries, turning serverless function deployment features into a path for host-level access and potential **cluster takeover**. Separately, a malicious Rust crate, **`onering` 1.4.1**, was also reported on the same day after being uploaded to crates.io with code designed to exfiltrate project metadata and source code before being removed roughly six hours later, though no evidence of actual use was reported.
Jun 29, 2026
Datadog Security Labs detailed **CVE-2020-8561**, an unpatchable Kubernetes weakness that can turn the `kube-apiserver` into a high-impact server-side request forgery (**SSRF**) proxy. An attacker with valid Kubernetes credentials and elevated privileges, typically `cluster-admin`, can abuse a `ValidatingWebhookConfiguration` object to make the API server send requests to attacker-controlled or internal destinations. By combining that behavior with profiling-enabled log-level changes, the attacker can cause the API server to log full responses from those privileged network requests rather than merely confirming whether a port is reachable. The issue is most dangerous when the Kubernetes control plane sits in a more trusted network segment than worker nodes, including managed Kubernetes environments hosted inside cloud provider networks. Because there is no straightforward code fix, defenders are being urged to reduce exposure through configuration and architecture changes, notably disabling API server profiling with: ```bash --profiling=false ``` and ensuring that SSRF originating from the API server cannot reach sensitive internal services or metadata endpoints.
Jun 29, 2026