Kubernetes has become the de facto standard for container orchestration, and with that dominance comes an ever-expanding attack surface. From misconfigured RBAC policies to critical API server vulnerabilities, the threat landscape around Kubernetes clusters is maturing rapidly. Staying current on CVEs, upstream patches, and security advisories is no longer optional for teams running production workloads.
This post covers the most significant recent Kubernetes security developments, what they mean for your cluster posture, and the concrete steps security engineers can take to assess and remediate exposure.
The Kubernetes project publishes security advisories through the official GitHub Security Advisories page and the kubernetes-announce mailing list. In recent release cycles, the project has disclosed vulnerabilities spanning the API server, ingress-nginx, kubelet, and the authorization subsystem. Several of these carry CVSS scores above 8.0, placing them firmly in the critical-to-high range.
Security teams that delay patching Kubernetes components risk more than a single compromised pod. A successful exploit against the API server or kubelet can lead to full cluster takeover, lateral movement into adjacent namespaces, and exfiltration of secrets stored in etcd.
If your organization needs a structured approach to Kubernetes hardening and cloud-native threat modeling, the Redfox Cybersecurity services team works with engineering teams to identify and close these gaps before adversaries do.
One of the most significant vulnerabilities disclosed in early 2025 affects ingress-nginx, the widely deployed ingress controller. This flaw, tracked as CVE-2025-1767, allows an attacker with the ability to create or modify Ingress objects to inject arbitrary NGINX configuration directives through the nginx.ingress.kubernetes.io/mirror-target annotation. In clusters where multi-tenant users can create Ingress resources, this leads to arbitrary code execution in the ingress-nginx pod, which typically runs with elevated privileges.
The upstream fix is included in ingress-nginx versions 1.11.5 and 1.12.1. Any cluster running an older version and allowing untrusted users to manage Ingress resources should treat this as an emergency patch.
To check your ingress-nginx version:
kubectl get pods -n ingress-nginx -o jsonpath='{.items[*].spec.containers[*].image}'
[cta]
To verify the annotation is not currently being abused in your cluster:
kubectl get ingress --all-namespaces -o json | \
jq '.items[] | select(.metadata.annotations."nginx.ingress.kubernetes.io/mirror-target" != null) | {name: .metadata.name, namespace: .metadata.namespace, annotation: .metadata.annotations."nginx.ingress.kubernetes.io/mirror-target"}'
[cta]
Any result returned here warrants immediate review. Legitimate use of this annotation is rare, and its presence in a multi-tenant cluster should be treated as a potential indicator of compromise or misconfiguration.
This vulnerability affects the kubelet's handling of certain pod configurations and can be triggered by a pod with permissions to manipulate node-local resources. An attacker who can schedule a malicious pod can crash the kubelet process, effectively taking the node offline and causing availability impact across all workloads on that node.
The fix is present in Kubernetes versions 1.29.13, 1.30.9, 1.31.5, and 1.32.1. Clusters on end-of-life minor versions are not receiving patches and should be upgraded.
Check your kubelet version across nodes with:
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}'
[cta]
For clusters running Windows worker nodes, CVE-2024-9042 allows a user with the ability to create pods to inject commands through the command field of a container spec on Windows nodes. The kubelet on Windows nodes did not properly sanitize certain inputs passed to the Windows process creation API.
This vulnerability is fixed in Kubernetes 1.29.4, 1.30.0, and later. If your cluster includes Windows nodes and you have not patched to at least these versions, any user with pod creation rights in any namespace should be treated as a potential attacker.
Beyond specific CVEs, the Kubernetes security community continues to flag authorization misconfigurations as one of the top vectors for privilege escalation. Several recent advisories have highlighted how combining individually low-risk RBAC permissions can produce a privilege escalation path that reaches cluster-admin.
A common pattern that threat actors and red teams exploit is the combination of create on pods and get on secrets within the same namespace. This allows an attacker to schedule a pod that mounts the target secret as a volume or environment variable and then reads it from inside the container.
A more dangerous combination is holding the bind verb on clusterrolebindings. This allows a user to bind any existing ClusterRole to any subject, effectively granting themselves or an external identity any role in the cluster, up to and including cluster-admin.
Audit your cluster for dangerous RBAC combinations using kubectl-who-can, a purpose-built tool for this use case:
# Install kubectl-who-can
kubectl krew install who-can
# Check who can bind ClusterRoles (critical escalation path)
kubectl who-can bind clusterrolebindings
# Check who can create pods in a sensitive namespace
kubectl who-can create pods -n kube-system
# Check who can read secrets cluster-wide
kubectl who-can get secrets --all-namespaces
[cta]
For a more comprehensive RBAC audit, rakkess provides a matrix view of access rights across all resource types:
# Install rakkess
kubectl krew install access-matrix
# Generate full access matrix for the current user
kubectl access-matrix
# Generate access matrix for a specific service account
kubectl access-matrix --sa kube-system:default
[cta]
Teams that regularly uncover privilege escalation paths through RBAC audits often benefit from a formal engagement with a cloud-native security firm. The Redfox Cybersecurity services team conducts Kubernetes red team exercises that mirror real-world attacker techniques, including RBAC abuse chains, to surface the paths most likely to be exploited in your specific environment.
etcd, the key-value store backing all cluster state, remains a top-priority hardening target. If etcd is accessible without authentication, an attacker can read every secret in the cluster in plaintext, including service account tokens, TLS certificates, and application credentials.
Recent penetration testing disclosures and bug bounty reports continue to surface etcd endpoints exposed without mutual TLS or with weak authentication configurations, particularly in self-managed clusters built with older tooling.
To check whether etcd requires client certificate authentication:
# From a node with etcdctl access
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
endpoint health
[cta]
If you can reach etcd without supplying client certificates, your cluster has a critical misconfiguration. To enumerate secrets directly from etcd (for authorized auditing purposes):
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
get /registry/secrets --prefix --keys-only
[cta]
Encrypting secrets at rest in etcd is a separate but equally important control. Verify encryption is configured by inspecting the API server manifest:
grep -i encryption-provider-config /etc/kubernetes/manifests/kube-apiserver.yaml
[cta]
If this flag is absent, secrets are stored in base64-encoded plaintext in etcd. The upstream documentation for encryption at rest covers the EncryptionConfiguration resource, which supports AES-CBC, AES-GCM, and KMS provider backends.
PodSecurityPolicy (PSP) was removed in Kubernetes 1.25. Clusters that migrated to the built-in Pod Security Admission (PSA) controller may have gaps if namespace labels were not properly configured during the transition. PSA enforces three profiles, privileged, baseline, and restricted, at the namespace level.
Audit your current namespace-level PSA configuration:
kubectl get namespaces -o json | \
jq '.items[] | {name: .metadata.name, labels: .metadata.labels}' | \
grep -A5 "pod-security"
[cta]
Namespaces with no pod-security labels are implicitly running under the privileged profile, meaning no restrictions apply. For production workloads, target the restricted profile at minimum.
Apply the restricted profile to a namespace:
kubectl label namespace production \
pod-security.kubernetes.io/enforce=restricted \
pod-security.kubernetes.io/enforce-version=latest \
pod-security.kubernetes.io/warn=restricted \
pod-security.kubernetes.io/warn-version=latest \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/audit-version=latest
[cta]
For teams using OPA Gatekeeper or Kyverno for policy enforcement, recent community advisories have highlighted scenarios where policy bypass is possible if the admission webhook is configured with failurePolicy: Ignore. In this configuration, if the webhook becomes unavailable, all admission requests are allowed through, bypassing every policy constraint.
Check your admission webhook failure policies:
kubectl get validatingwebhookconfigurations -o json | \
jq '.items[] | {name: .metadata.name, webhooks: [.webhooks[] | {name: .name, failurePolicy: .failurePolicy}]}'
kubectl get mutatingwebhookconfigurations -o json | \
jq '.items[] | {name: .metadata.name, webhooks: [.webhooks[] | {name: .name, failurePolicy: .failurePolicy}]}'
[cta]
Any webhook controlling security policy should use failurePolicy: Fail to ensure that a downed admission controller does not create an open window for policy bypass.
Patching and hardening reduce your attack surface, but runtime detection is essential for catching what static controls miss. Falco, the CNCF runtime security tool, provides kernel-level visibility into process execution, network connections, and file system activity within containers.
A targeted Falco rule to detect common post-exploitation behavior, specifically, running a shell inside a container that does not normally require one:
- rule: Shell Spawned in Non-Interactive Container
desc: Detects shell execution inside a container where interactive shells are not expected
condition: >
spawned_process and
container and
shell_procs and
not container.image.repository in (allowed_shell_images) and
not proc.pname in (known_shell_parents)
output: >
Shell spawned in container
(user=%user.name container=%container.name image=%container.image.repository
shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
priority: WARNING
tags: [container, shell, mitre_execution]
[cta]
For detecting potential API server reconnaissance, monitor for unusual kubectl exec or kubectl cp usage against production namespaces by auditing Kubernetes audit logs. The audit policy below captures exec and port-forward events at the request level:
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Request
resources:
- group: ""
resources: ["pods/exec", "pods/portforward", "pods/attach"]
verbs: ["create"]
- level: Metadata
resources:
- group: ""
resources: ["secrets", "configmaps"]
verbs: ["get", "list", "watch"]
- level: None
users: ["system:kube-proxy"]
verbs: ["watch"]
resources:
- group: ""
resources: ["endpoints", "services"]
[cta]
Enabling this audit policy and shipping logs to a SIEM gives your team the visibility needed to detect lateral movement and credential harvesting before attackers establish persistence.
The 2024 and 2025 Kubernetes advisory cycles have included multiple disclosures tied to compromised or malicious container images reaching production clusters. Enforcing image signature verification and software bill of materials (SBOM) policies is now a baseline expectation for secure clusters.
Sigstore's Cosign tool, integrated with Kyverno or Gatekeeper, allows you to enforce that only images signed by a trusted identity can be scheduled:
# Sign an image with Cosign using keyless signing
cosign sign --yes ghcr.io/your-org/your-image:latest
# Verify a signed image
cosign verify \
--certificate-identity=your-ci@your-org.iam.gserviceaccount.com \
--certificate-oidc-issuer=https://accounts.google.com \
ghcr.io/your-org/your-image:latest
[cta]
A corresponding Kyverno policy to enforce signed images cluster-wide:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-signed-images
spec:
validationFailureAction: Enforce
rules:
- name: check-image-signature
match:
any:
- resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "ghcr.io/your-org/*"
attestors:
- count: 1
entries:
- keyless:
subject: "your-ci@your-org.iam.gserviceaccount.com"
issuer: "https://accounts.google.com"
[cta]
Coupling image signing enforcement with a verified SBOM requirement, using the cosign attach sbom and cosign verify-attestation commands, closes the supply chain visibility gap that has fueled several recent incidents.
Teams looking to implement a full supply chain security program across their Kubernetes environments, from image provenance through runtime policy, can work with Redfox Cybersecurity to design controls that fit their existing CI/CD pipelines and deployment models.
Kubernetes security is not a one-time configuration exercise. The CVEs and advisories published in the past several months make clear that attackers are targeting every layer of the stack, from ingress controllers and kubelet processes to RBAC configurations, etcd, and the software supply chain.
The most effective approach combines timely patching against published CVEs, continuous RBAC auditing to catch privilege escalation paths, runtime detection through tools like Falco and structured audit logging, and supply chain controls enforced at admission time through signed images and SBOM attestation.
Running these controls in isolation is less effective than integrating them into a layered security program with clear ownership and response playbooks. If your team is building or maturing a Kubernetes security practice and needs external expertise to accelerate it, the Redfox Cybersecurity services team provides cloud-native security assessments, red team exercises, and remediation guidance tailored to the Kubernetes environments that organizations actually run in production.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
