Home/Blog/Vulnerability Research
Vulnerability ResearchPublished · Updated ⚡ 15 min read

Stop shipping default K8s configs. Fix these 15 footguns before you get breached.

A gritty, zero-BS guide to the 15 most critical Kubernetes security misconfigurations in 2026, complete with vulnerable vs hardened YAML examples.

VG
Vladyslav Gusarov
DevSecOps Lead at Bryxe
Kubernetes Security: 15 Misconfigurations That Will Get Your Cluster Owned [2026 Data]

Look, I'm tired of seeing the same stupid mistakes. You spin up a cluster, slap some manifests together, and call it a day. Then six months later you're wondering why a cryptominer is eating up your AWS bill. Default Kubernetes is not secure. It's a loaded gun pointed at your production environment.

Bottom line: if you're not locking down these 15 misconfigurations, you are begging to get owned. Let's tear them apart. I'm going to go deep here because skimming the surface is exactly how you end up on the front page of a tech blog for a massive data breach.

We've all been there. You're trying to hit a sprint deadline, so you just copy-paste some YAML from Stack Overflow. It works. The app is running. You ship it to prod. But under the hood, that janky YAML is a ticking time bomb. The reality of Kubernetes security in 2026 is that attackers are automated. They aren't sitting at a keyboard typing commands; they have scripts scanning the entire internet for exposed API servers and open ports.

This isn't a game anymore. We are dealing with highly motivated ransomware gangs. They scan for open kubelets. They exploit RBAC misconfigurations in seconds. Let's dig deeper.

1. Privileged Containers

Running privileged containers is literally giving root access to the host node. Stop doing this. I don't care if your janky monitoring agent needs it. Fix the agent. When you set privileged: true, you are telling the container runtime to disable all security mechanisms. Seccomp? Gone. AppArmor? Ignored. Capabilities? All of them.

Honestly, it's a nightmare. An attacker who lands in a privileged container can just mount the host filesystem, chroot into it, and add their own SSH keys to the node. Game over. You just handed them the keys to the kingdom.

Vulnerable:

yamlSource Code
apiVersion: v1
kind: Pod
metadata:
  name: owned-pod
spec:
  containers:
  - name: app
    image: nginx
    securityContext:
      privileged: true

Hardened:

yamlSource Code
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
  - name: app
    image: nginx
    securityContext:
      privileged: false
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

2. hostPID

Sharing the host's PID namespace means your pod can see and interact with every process on the node. An attacker breaks out of the pod and they can just kill -9 your kubelet or steal secrets from other processes.

If an attacker has RCE in a pod with hostPID enabled, they can use tools like nsenter to jump into other namespaces. They can dump the memory of running processes. If you have a database process running on the same node, they can extract credentials right out of RAM. This is a massive footgun.

Vulnerable:

yamlSource Code
apiVersion: v1
kind: Pod
metadata:
  name: snooper-pod
spec:
  hostPID: true
  containers:
  - name: app
    image: busybox

Hardened:

yamlSource Code
apiVersion: v1
kind: Pod
metadata:
  name: isolated-pod
spec:
  hostPID: false
  containers:
  - name: app
    image: busybox

3. hostNetwork

Similar garbage. You map the pod to the node's network space. Now your pod bypasses network policies and can snoop on node traffic. Nuke it.

When a pod uses the host network, it gets the exact same network access as the node itself. It bypasses any CNI-level network policies you've painstakingly set up. An attacker can bind to localhost ports that are supposed to be secure, like the kubelet's read-only port, or sniff traffic meant for other pods on the node using tcpdump. It's a network isolation nightmare.

Vulnerable:

yamlSource Code
apiVersion: v1
kind: Pod
metadata:
  name: network-bypass
spec:
  hostNetwork: true

Hardened:

yamlSource Code
apiVersion: v1
kind: Pod
metadata:
  name: network-isolated
spec:
  hostNetwork: false

4. Missing Network Policies

By default, K8s is a flat network. Every pod can talk to every other pod. If one web frontend gets popped, the attacker can just curl your backend database. Implement default-deny.

I see this in almost every audit. Teams spend weeks configuring firewalls outside the cluster, but inside? It's the Wild West. You need to restrict lateral movement. If a frontend pod doesn't need to talk to the payment gateway, block it.

Vulnerable: Doing nothing. Relying on default settings.

Hardened:

yamlSource Code
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Add explicit allow rules for what actually needs to communicate.

5. Overly Permissive RBAC

Cluster-admin for everyone? Great idea if you hate your job. Keep RBAC tight. Least privilege isn't just a buzzword, it's what keeps you off the news.

Honestly, it's a nightmare. People get frustrated with RBAC because it's verbose. So they just slap a wildcard on the role and call it a day. But * verbs and * resources mean anyone with that role can do anything. They can read secrets, delete deployments, or spin up privileged pods. Audit your roles.

Vulnerable:

yamlSource Code
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: sloppy-dev
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

Hardened:

yamlSource Code
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: restricted-dev
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

6. Default Service Accounts

Every namespace gets a default service account. By default, K8s mounts its token into every pod. If your app has an SSRF or LFI, boom, they have the API token. Turn off automounting.

An attacker grabs that token from /var/run/secrets/kubernetes.io/serviceaccount/token and starts querying your API server. Even if the default account doesn't have permissions, it's information disclosure. And if someone accidentally bound a role to default? You're smoked.

Hardened:

yamlSource Code
apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
automountServiceAccountToken: false

7. Exposed Dashboards

If you're still exposing the Kubernetes Dashboard to the internet without authentication in 2026, you deserve what's coming. Just don't install it. Use CLI or a managed service.

We saw massive automated campaigns exploiting exposed dashboards years ago, and somehow, people are still doing it. A dashboard with a bound service account is literally a point-and-click interface for cluster takeover. Nuke the dashboard. If your devs can't use kubectl, they shouldn't be touching the cluster.

8. Missing Pod Security Standards

PSPs are dead. Pod Security Admission is in. Enforce restricted policies at the namespace level.

If you don't enforce baseline or restricted policies, devs will just run pods as root. PSA is built-in. Use it. Label your namespaces and let the admission controller block the bad stuff before it ever schedules.

Hardened:

yamlSource Code
apiVersion: v1
kind: Namespace
metadata:
  name: prod
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted

9. Unscanned Images

Pulling latest from Docker Hub and shipping to prod. What could go wrong? Supply chain attacks are real. Scan your images in CI/CD and use admission controllers to block critical CVEs.

I'm tired of seeing this in PRs. You need to know what's in your containers. A vulnerable version of Log4j or OpenSSL hidden in some base image you pulled off a random registry is a ticking time bomb. Use tools like Trivy or Grype. Better yet, use distroless images. Stop shipping curl, wget, and bash to production environments. Attackers love it when you pre-install their toolchain.

10. Missing Resource Limits

No limits means one compromised pod can crash the entire node by eating all the memory. It's a trivial DoS.

Cryptominers will peg your CPU to 100%. If you don't have limits, your legit apps get throttled and eventually OOMKilled. Set requests and limits for everything. Enforce it with LimitRanges.

Hardened:

yamlSource Code
apiVersion: v1
kind: Pod
metadata:
  name: limited-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "512Mi"

11. etcd Without TLS

etcd is the brain of your cluster. If someone can read it, they own everything. Encrypt it in transit and at rest.

If you're managing your own control plane and your etcd is unencrypted, an attacker who gets onto a master node can just dump the database. That means plaintext access to every secret in the cluster. Turn on EncryptionConfiguration.

12. Secrets in Plaintext

Base64 is not encryption. Stop committing secrets to Git. Use External Secrets Operator or SOPS.

I can't count the number of times I've found AWS keys base64-encoded in a Secret manifest sitting in a public GitHub repo. Base64 can be decoded by an 8-year-old. Integrate your K8s cluster with a real vault, like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault.

13. Missing Audit Logging

If you don't have audit logs, you have no idea who did what when the breach happens. Enable the audit backend and ship logs to a secure SIEM.

Look, I've seen this a hundred times. When the incident response team shows up, the first thing they want is the Kube API audit logs. If you turned them off to save disk space, you're flying blind. You won't know if the attacker dumped secrets, created rogue pods, or added backdoors.

14. Ingress Without TLS

Unencrypted HTTP traffic in 2026? Cert-manager is free. Let's Encrypt is free. Stop being lazy.

There's zero excuse for not terminating TLS at your Ingress. Exposing internal services over plaintext HTTP on the internet means your session tokens and credentials can be sniffed by anyone sitting on the wire.

15. Sidecar Injection Bypass

If you use a service mesh, make sure attackers can't bypass the sidecar proxies by setting weird annotations or host networking. Enforce sidecars via strict admission webhooks.

Service meshes like Istio or Linkerd are great for mTLS and zero-trust, but if a developer (or an attacker) can just add an annotation sidecar.istio.io/inject: "false", they completely bypass all your fancy security policies.

Look, Kubernetes is a beast. But if you fix these 15 things, you're ahead of 90% of the industry. Go check your clusters now. Stop guessing and start locking things down.

AUTOMATED DEFENSE

Don't wait for an exploit to audit your codebase

Review supported code risks, exposed secrets and dependency findings with Bryxe Shield. Verify the fixes in your application before release.

Need a practical next step? Explore the security field guides or read our editorial and sourcing policy.

Recommended Security Research