CVE-2025-29778 - Kyverno Keyless Signature Bypass Allows Full Kubernetes Compromise

Kyverno is a popular policy engine used by platform engineering teams to keep Kubernetes clusters secure and compliant. It helps automate best practices and enforces policies on your Kubernetes resources. However, a critical security vulnerability, CVE-2025-29778, affected Kyverno before version 1.14.-alpha.1. In this article, we'll break down what went wrong, why it was dangerous, and how you can keep your clusters safe now.

What is CVE-2025-29778?

In Kyverno versions before 1.14.-alpha.1, the system overlooked crucial security checks when running in keyless signature verification mode. Specifically, the policy engine ignored subjectRegExp and issuerRegExp settings. These settings are meant to verify who signed an artifact and which certificate authority issued the signature.

By ignoring these checks, attackers could deploy Kubernetes resources signed by unauthorized or rogue certificates, bypassing the cluster's security policies entirely. In the worst-case scenario, this could lead to a *full compromise of your Kubernetes cluster*.

Why Did This Happen?

Kyverno uses cosign and Sigstore tools for verifying container image signatures. You can write policies that restrict deployments to images signed by certain organizations or issued by specific authorities, using the subjectRegExp and issuerRegExp fields.

Due to a bug, when Kyverno was set to keyless mode (meant to allow for Sigstore Keyless signatures), it wasn't enforcing checks for these fields at all.

Here's a simplified code snippet showing how things looked before the patch

// Old logic (vulnerable)
if verificationMode == "keyless" {
    // Skipped checking subjectRegExp and issuerRegExp!
    verifyOnlySignature(artifact)
} else {
    verifySignatureAndCheckCertificate(artifact, subjectRegExp, issuerRegExp)
}

This meant anyone could use any keyless certificate to sign and deploy resources, regardless of your policy restrictions.

An attacker creates a Kubernetes resource, such as a malicious deployment.

2. They use any keyless certificate to sign the artifact; the identity or authority does not matter.
3. Kyverno, running with a vulnerable version, treats this artifact as trusted—even if your policy intended to limit signers!

The malicious resource is admitted and deployed into your cluster.

Consequences:
- Attackers could run privileged containers, mine cryptocurrency, exfiltrate sensitive data, or escalate privileges, leading to full cluster compromise.

Suppose you intended to only allow images signed by your company's CI

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-trusted-signature
spec:
  validationFailureAction: enforce
  rules:
    - name: validate-signature
      match:
        resources:
          kinds:
          - Pod
      verifyImages:
      - image: "*"
        keyless:
          subjectRegExp: ".*@mycompany.com"
          issuerRegExp: "https://accounts.google.com";

Expected: Only @mycompany.com signers are allowed.
Vulnerable behavior: Any keyless-signed image would be accepted!

So, an attacker could run

cosign sign --keyless ghcr.io/my-malicious-app

And then deploy their app into your cluster, completely bypassing the strict signer requirements.

Patch and Mitigation

Kyverno v1.14.-alpha.1 fixes this by properly verifying the subjectRegExp and issuerRegExp conditions, even in keyless signature mode.

Patched logic

// Fixed logic (patched)
if verificationMode == "keyless" {
    verifySignatureAndCheckCertificate(artifact, subjectRegExp, issuerRegExp)
} else {
    // ...
}

How to protect yourself

- Upgrade: Immediately update to at least Kyverno v1.14.-alpha.1 or above.
- Audit: Review your Kyverno policies and double check admission logs for suspicious deployments during the vulnerability window.
- Limit privileges: Apply strict RBAC and network policies as defense-in-depth, so one compromised pod can’t snowball cluster-wide.

References and Further Reading

- Kyverno Security Advisory (CVE-2025-29778) *(replace with actual GHSA link)*
- Kyverno Release Notes v1.14.-alpha.1
- Mitigating Keyless Verification Risks (Kyverno Docs)

Conclusion

Any Kubernetes cluster running a vulnerable Kyverno version is at high risk. Don’t wait—patch now! Even one overlooked security bug at the policy layer can put your entire infrastructure in jeopardy. Always follow project release notes and security advisories to keep your clusters locked down.

Timeline

Published on: 03/24/2025 17:15:20 UTC
Last modified on: 03/27/2025 16:45:46 UTC