Leaked Kubernetes Secrets: Impact Assessment and Mitigation Strategies

Threat-intel reports from recent years document campaigns in which attackers obtain AWS IAM credentials from developer workstations, use them to enumerate cloud accounts and access Kubernetes clusters. From there, attackers deploy poisoned container images to move laterally and harvest secrets. The MITRE ATT&CK chain maps to: T1552.001 ( Credentials in Files ) → T1078.004 ( Valid Accounts: Cloud Accounts ) → T1610 ( Deploy Container ) → T1496 ( Resource Hijacking ).This is not an isolated case. The Shai-Hulud supply chain attack harvested Kubernetes credentials from CI and developer workstations, feeding exactly this kind of attack chain.

This research started with a short list of questions:

So before we look at what we found in the wild, and how to harden clusters to mitigate impacts, let's define what Kubernetes secrets are.

A simplified view of the cluster has three sides that matter for this post:

These are the attack surfaces where leaked secrets have the most impact, and three secret formats unlock them:

These three formats, TLS, JWT, Docker config JSON, are what we will detect, validate, and exploit below.

A kubeconfig is a one-file credential. Leaking it leaks the cluster.

In this example, the client-certificate-data and client-key-data fields are the actual credential. Everything else is configuration. You don't need kubectl to confirm one of these works. The API server is just an HTTPS service, and curl is enough.

--insecure is fine here as we are validating the client credential, not the server's identity. A successful response means that credentials are valid. JWTs can be tested the same way.

The credentials we found in the wild are almost always over-privileged. With them, an attacker has several options:

For example, we found one valid JWT pulled from a public Docker image that gave us access to a cluster. The cluster's Secrets contained valid registry credentials. Those credentials, in turn, opened private Docker Hub images and private GitHub organizations.

For a deeper exploration of post-compromise persistence inside Kubernetes, the Insomni'hack 2025 talk on the topic ( is worth a read.

None of the mitigations are exotic:

Registry credentials live inside the cluster as Secret objects:

Here the .dockerconfigjson field contains the real credential encoded in base64. A short jq command unwraps the structure:

From there, validating and using the credential is a docker login away:

For ECR, ACR, and similar managed registries, you will first exchange your static credential for a bearer token before pulling.Three operations matter once you are authenticated: pull (read), push (write), and enumerate the images.

The interesting twist registry credentials is that they rarely scope to the registry alone:

So one leaked registry secret typically gives an attacker:

Most of what we documented would have been prevented by three habits:

• Use private container registries: public registries are not a place to store private artifacts.

• Read-only credentials wherever possible. Your cluster only needs pull. It does not need push, and it certainly does not need repo scope on GitHub.

• Revoke at decommission. When a cluster goes away, revoke its registry credentials too. The data shows that registry credentials regularly outlive the clusters they served.

In fall 2025, we scanned public GitHub and Docker Hub for the three secret formats and validated every match. Here is what we found.

• 44 unique active clusters in total. Four had more than 10 nodes, and one had more than 200 nodes: a serious production environment.

• 30% of these clusters had been exposed for more than two years. The oldest still valid leak dated back to 2021.

• Only 10% of the leaked secrets had been deleted from their source. The rest were still sitting where they were originally published. Typically because the developer deleted the commit but never rotated the credential.

One pattern stood out: valid JWTs were almost exclusively found on Docker Hub, not GitHub. Our theory is that certificates leak when humans accidentally commit a kubeconfig, while JWTs leak when service accounts are baked into container images during a CI build.

• 2,034 registry credentials with resolvable hostnames.

• Provider breakdown: 1,025 Docker Hub, 480 GitHub, 276 Quay, 249 GitLab, 59 Azure.

• 46% of resolvable credentials were still valid.

• 309 private Docker Hub images discovered through these credentials.

• 730 private GitHub repositories accessible: not from a GitHub leak, but from a Kubernetes Secret leak.

• Some leaks were as old as 2022 and still valid.

GitGuardian already notifies developers when their leaked credentials are detected on public GitHub. Here, we went one step further: up the chain from the developer to the company. Mapping a credential back to its owner is its own research task: pod names, hostnames, all became identification clues. In total, we contacted 11 companies:

• Kubernetes API server: 7 owners identified and contacted

• Container registries: 4 owners identified and contacted.

Most of that work was spent finding the right person to email. RFC 9116 ( /.well-known/security.txt ) would have really helped us here. If you operate an internet-facing service, please consider implementing it.

This work fed into the detection and validity engines inside GitGuardian. Both the Kubernetes TLS-certificate and JWT checkers, and the container-registry checker, were tuned during the research and are now consistently catching new leaks across the providers we covered (Docker Hub, GitHub, GitLab, Quay, Azure).

In Q1 2026 alone, those detectors found close to 2,000 new Kubernetes secret leaks on GitHub; 28% valid at leak time.

Leaked Kubernetes secrets are diverse, misconfigurations make them worse, and the lateral-movement scenarios are real. None of the hardening recommendations above are new: they are already well documented. The work is in applying them, and in catching the leaks early when they slip through.