Loading story…
Kubernetes 1.37 advances several platform-security controls, including rootless kubelet operation, short-lived service-account credentials for image pulls, authenticated API-server-to-webhook communication, and hardened volume-mount controls. The release also prohibits static Pods from referencing Secrets or ConfigMaps, while exposing additional API-visible operational and resource-health data that could aid reconnaissance where API permissions are overly broad.
The release stabilizes SELinux mount labeling for eligible volumes, completing work initiated under KEP 1710 to mount volumes with the correct SELinux label rather than recursively relabeling every file at container startup. Administrators should test shared-volume labeling scenarios, adopt short-lived credentials, restrict API access, and verify that security tooling supports nftables as kube-proxy warns iptables users ahead of nftables becoming the default in Kubernetes 1.40.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
Kubernetes v1.37 made Pod Certificates and ClusterTrustBundles stable, providing native distribution of private keys, X.509 certificates, and trust bundles to Pods.
Kubernetes opened Enhancement Proposal 1710 to speed container startup by applying the correct SELinux label when mounting volumes instead of recursively relabeling every file. SIG Storage and SIG Node were responsible for the proposal, with jsafrane as primary contact.
Kubernetes 1.37 graduates the SELinuxMount feature to stable, applying SELinux context labeling at mount time for eligible PersistentVolumes. The feature can create issues where Pods with differing SELinux labels or privilege levels share a volume.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
4 references tracked. Mallory keeps watching after this page renders.
kubernetes.io
Open sourcekubernetes.io
Open sourcewebflow.sysdig.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.
KubeCap, a research framework for least-privilege Kubernetes deployments, maps rendered manifests, container entry points, reachable Go code, syscall arguments, and Linux kernel capability checks to identify capabilities that workloads do not require. Across 10 Go-based Kubernetes projects, researchers found that **74.67%** did not explicitly configure Linux capabilities and reported an average **54.97%** reduction after applying KubeCap-generated policies. In testing of Amazon VPC CNI, `CAP_NET_RAW` was removable from the `aws-node` component without affecting tested cluster connectivity, although `CAP_NET_ADMIN` and privileged execution remained necessary in that environment. The findings reinforce Kubernetes hardening guidance to define container security contexts explicitly rather than rely on defaults. Organizations should run workloads with the minimum required capabilities, disable privilege escalation where feasible, use non-root user and group identities, apply seccomp, AppArmor, or SELinux controls, and use read-only root filesystems when compatible. Capability-removal recommendations require human review and representative functional testing because KubeCap's static analysis, LLM-assisted kernel-rule extraction, and Linux-version assumptions can produce incomplete results; teams should also account for implicit supplementary groups from container image `/etc/group` files and consider `supplementalGroupsPolicy: Strict` to prevent unintended group membership.
Aug 29, 2026
Kubernetes maintainers disclosed five critical vulnerabilities in **ingress-nginx**, including **`CVE-2025-1974`** with a **CVSS 9.8** rating, warning that attackers on the Pod network could abuse configuration injection in the Validating Admission Controller to take over clusters without credentials. The flaws also affect how ingress-nginx builds **NGINX** configuration from crafted Ingress objects, potentially exposing Secrets available to the controller and leading to full cluster compromise. Patched releases **`ingress-nginx v1.12.1`** and **`v1.11.5`** were issued, and operators were urged to upgrade immediately or temporarily disable the Validating Admission Controller until patching is complete. The disclosure adds to broader concerns about Kubernetes networking and multi-tenant isolation, highlighted by **`CVE-2021-25740`**, an unpatchable issue that lets users with permission to modify **Endpoint** or **EndpointSlice** objects redirect service traffic to unauthorized IP addresses. In shared ingress-controller or load-balancer deployments, that behavior can allow one tenant to steer traffic into another tenant’s workloads and bypass intended network boundaries. Security researchers and vendors said the combined risk is highest in clusters that rely on shared ingress infrastructure with broad Secret access, and recommended tightening EndpointSlice permissions, avoiding shared ingress designs in sensitive environments, and evaluating the **Gateway API** as a safer architecture.
Jun 29, 2026
New technical writeups highlighted how seemingly *read-only* Kubernetes permissions can be escalated into **remote code execution (RCE)** by abusing access paths to the **kubelet** API. Horizon3.ai detailed a technique where a service account granted `nodes/proxy` **GET** (often treated as “read-only” for monitoring/log access) can, if it also has network reachability to the kubelet, be leveraged to execute commands in pods on reachable nodes—an outcome the Kubernetes project has largely treated as **“working as intended”** rather than a traditional vulnerability. The post emphasizes that this can translate into broad cluster compromise in many real environments and points to mitigations such as tightening RBAC and adopting controls aligned with **KEP-2862** and vendor RBAC hardening guidance. Separately, a bug-bounty case study described an end-to-end **cloud-native kill chain** culminating in Kubernetes takeover: an initial **SSRF** in a microservice was used to access **EC2 instance metadata** and steal cloud credentials, which then enabled kubelet API abuse to deploy a rogue privileged pod. From that foothold, the attacker obtained a more powerful Kubernetes service account token and escalated to `cluster-admin`, resulting in full cluster control and a reported **$100,000** responsible disclosure payout. While the initial access vectors differ, both accounts reinforce that kubelet exposure plus permissive RBAC/service-account design can turn “limited” access into cluster-wide impact, making kubelet reachability and `nodes/proxy`/kubelet-related permissions high-priority review items for Kubernetes security programs.
Jun 29, 2026