Loading story…
Kubernetes has promoted KYAML, a stricter YAML subset for Kubernetes manifests, from alpha in v1.34 to beta and enabled by default in v1.35. KYAML remains optional and compatible with existing YAML parsers and Kubernetes tooling, but makes configuration structure and types explicit through braces for objects, brackets for arrays, and double-quoted strings.
The project provides kubectl -o kyaml output and formatting tools to convert existing manifests incrementally. Kubernetes positions the format as a way to reduce errors caused by YAML formatting and implicit typing, particularly in generated configuration from Helm, GitOps, infrastructure-as-code systems, and AI coding agents, while improving validation consistency and code review readability.
See the reporting duties and controls this puts on the clock.
2 events from the most recent confirmed update back to the earliest known activity.
Kubernetes moved KYAML to beta status and enabled it by default in Kubernetes v1.35, while keeping conventional YAML supported and KYAML optional.
Kubernetes introduced KYAML, a stricter YAML subset for manifests, as an alpha feature in Kubernetes v1.34.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See what this changes for your reporting obligations and which controls it puts on the clock.
2 references tracked. Mallory keeps watching after this page renders.
Map 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.
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.
Aug 29, 2026
The Cloud Native Computing Foundation released **Kubernetes 1.37**, codenamed *Garhwal*, with 67 enhancements focused on platform stability, security, and AI/ML workloads. The release promotes the Metrics API, resilient watch-cache initialization, and pod certificates to stable availability, while moving rootless Kubelet operation to beta, reducing the privilege requirements of node-level Kubernetes components. Kubernetes 1.37 also introduces alpha support for pod checkpoint and restore, an effort supported by the Kubernetes Checkpoint/Restore Working Group, alongside workload-aware scheduler preemption and StatefulSet `Recreate` rollouts. The release includes 27 alpha features, 23 beta graduations, 16 stable graduations, and one deprecation or removal.
Sep 21, 2026
A critical privilege-escalation vulnerability in **Kyverno** tracked as `CVE-2026-54523` allows a low-privileged Kubernetes tenant to gain access across namespaces, including `kube-system`, by abusing the `NamespacedGeneratingPolicy` feature. The flaw affects **Kyverno 1.18.1 and earlier** and stems from missing validation in the CEL-based `generator.apply()` path, where Kyverno fails to ensure the target namespace matches the policy’s own namespace. Public disclosure included full technical details and proof-of-concept exploit code. By creating a malicious `NamespacedGeneratingPolicy`, an attacker can trick Kyverno’s background controller—typically granted cluster-wide RBAC permissions—into generating resources in arbitrary namespaces. That can enable creation of privileged objects such as **RoleBindings**, potentially leading to admin-level access and broader manipulation of **ConfigMaps**, **NetworkPolicies**, and **Ingresses** across a cluster. The issue is fixed in **Kyverno 1.18.2**; defenders are urged to upgrade immediately, restrict who can create `NamespacedGeneratingPolicy` objects, audit existing policies for cross-namespace targets, and monitor sensitive namespaces for unexpected `Role` or `RoleBinding` creation. No confirmed in-the-wild exploitation was reported at publication time.
Jul 17, 2026