Kubernetes

CVE-2025-29778: Kyverno Ignores subjectRegExp and IssuerRegExp Leading to Improper Authorization

Robert Morgan

Robert Morgan

— 5 min read

Executive Summary

CVE-2025-29778 is a security vulnerability affecting Kyverno, a policy engine designed for Kubernetes. This vulnerability allows attackers to bypass intended authorization controls by exploiting the fact that Kyverno versions prior to 1.14.0-alpha.1 incorrectly ignore the subjectRegExp and IssuerRegExp fields during keyless signature verification. This oversight enables the deployment of Kubernetes resources with artifacts signed by unexpected certificates, potentially leading to a full compromise of the Kubernetes cluster. The vulnerability is classified as CWE-285 (Improper Authorization) and has a CVSS v3.1 base score of 5.8 (Medium).

Technical Details

The vulnerability resides in the keyless signature verification process within Kyverno. Keyless verification allows Kyverno to verify signatures without requiring pre-configured public keys. Instead, it relies on information embedded within the signature itself, such as the subject and issuer of the signing certificate. The subjectRegExp and IssuerRegExp fields are intended to provide a mechanism for administrators to define regular expressions that the subject and issuer of the signing certificate must match for the signature to be considered valid.

Affected systems include any Kubernetes cluster running Kyverno versions prior to 1.14.0-alpha.1. The vulnerable component is the pkg/cosign/cosign.go file within the Kyverno codebase, specifically the matchSignatures function.

Root Cause Analysis

The root cause of CVE-2025-29778 lies in an insufficient conditional check within the matchSignatures function. Prior to the patch, the function only checked if the subject and issuer fields were empty, along with the length of the extensions map. It failed to consider the subjectRegExp and IssuerRegExp fields. This oversight meant that even if these regular expression fields were defined with specific requirements, they were effectively ignored during the signature verification process.

Here's the relevant code snippet from the vulnerable version of pkg/cosign/cosign.go:

func matchSignatures(signatures []oci.Signature, subject, subjectRegExp, issuer, issuerRegExp string, extensions map[string]string) error {
	if subject == "" && issuer == "" && len(extensions) == 0 {
		return nil
	}

	// ... rest of the function
}

The above code demonstrates that if subject, issuer, and extensions are all empty, the function immediately returns nil, effectively bypassing any further signature validation, including checks against subjectRegExp and issuerRegExp. This allows any signature, regardless of its subject or issuer, to be considered valid as long as the subject and issuer strings are empty and no extensions are present.

Patch Analysis

The fix for CVE-2025-29778 involves modifying the conditional check within the matchSignatures function to include subjectRegExp and issuerRegExp. The patch ensures that the function only returns nil (indicating a successful match) if all relevant fields, including the regular expression fields, are empty.

Here's the diff output showing the changes made to pkg/cosign/cosign.go:

File: pkg/cosign/cosign.go
--- a/pkg/cosign/cosign.go
+++ b/pkg/cosign/cosign.go
@@ -534,7 +534,7 @@ func extractDigest(imgRef string, payload []payload.SimpleContainerImage) (strin
 }
 
 func matchSignatures(signatures []oci.Signature, subject, subjectRegExp, issuer, issuerRegExp string, extensions map[string]string) error {
-	if subject == "" && issuer == "" && len(extensions) == 0 {
+	if subject == "" && issuer == "" && subjectRegExp == "" && issuerRegExp == "" && len(extensions) == 0 {
 		return nil
 	}

The patch adds subjectRegExp == "" && issuerRegExp == "" to the if condition. This ensures that the function only returns nil if subject, issuer, subjectRegExp, issuerRegExp, and extensions are all empty. This change enforces the intended behavior of validating signatures against the provided regular expressions, preventing unauthorized artifacts from being deployed.

The corrected code snippet now looks like this:

func matchSignatures(signatures []oci.Signature, subject, subjectRegExp, issuer, issuerRegExp string, extensions map[string]string) error {
	if subject == "" && issuer == "" && subjectRegExp == "" && issuerRegExp == "" && len(extensions) == 0 {
		return nil
	}

	// ... rest of the function
}

This seemingly small change has a significant impact on the security of Kyverno, as it ensures that the subjectRegExp and issuerRegExp fields are properly considered during signature verification.

Exploitation Techniques

An attacker can exploit CVE-2025-29778 by crafting a Kubernetes resource that references a container image signed with a certificate that does not match the expected subjectRegExp and issuerRegExp. Because Kyverno versions prior to 1.14.0-alpha.1 ignore these fields, the signature verification will succeed, and the attacker will be able to deploy the malicious resource.

Here's a step-by-step Proof of Concept (PoC) example:

  1. Create a Kyverno policy that uses subjectRegExp and issuerRegExp:

    apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-image
spec:
  validationFailureAction: enforce
  rules:
    - name: check-image-signature
      match:
        any:
        - resources:
            kinds:
            - Pod
      verifyImages:
      - imageReferences:
        - "image"
        keyless:
          subjectRegExp: ".*@example\\.com$"
          issuerRegExp: "https://github.com/login/oauth"

    This policy requires that all Pods use container images signed with a certificate whose subject matches the regular expression .*@example\.com$ and whose issuer is https://github.com/login/oauth.

  2. Create a container image and sign it with a certificate that does not match the policy:

    Assume an attacker has created a malicious container image and signed it with a certificate whose subject is attacker@evil.com and whose issuer is https://evil.com.

  3. Create a Kubernetes Pod that uses the malicious image:

    apiVersion: v1
kind: Pod
metadata:
  name: malicious-pod
spec:
  containers:
  - name: malicious-container
    image: <attacker-registry>/malicious-image:latest

  4. Apply the Pod to the Kubernetes cluster:

    kubectl apply -f malicious-pod.yaml

    In a vulnerable Kyverno version, the Pod will be successfully created, even though the image signature does not match the policy's subjectRegExp and issuerRegExp. This is because Kyverno ignores these fields during verification.

  5. Real-world impact:

    By deploying unauthorized Kubernetes resources, an attacker can gain control over the cluster. This could lead to data exfiltration, denial of service, or even complete cluster takeover.

Mitigation Strategies

To mitigate CVE-2025-29778, the following steps should be taken:

  1. Upgrade Kyverno: Upgrade to Kyverno version 1.14.0-alpha.1 or later. This version contains the patch that fixes the vulnerability.

  2. Review Existing Policies: After upgrading, review all existing Kyverno policies that use subjectRegExp and issuerRegExp to ensure they are configured correctly.

  3. Implement Security Best Practices: Follow general Kubernetes security best practices, such as:

    • Principle of Least Privilege: Grant users and service accounts only the minimum necessary permissions.
    • Network Segmentation: Isolate sensitive workloads in separate network segments.
    • Regular Security Audits: Conduct regular security audits to identify and address potential vulnerabilities.

  4. Alternative Solutions (if immediate upgrade is not possible):

    While upgrading is the recommended solution, if an immediate upgrade is not feasible, consider these temporary workarounds:

    • Avoid Keyless Verification: If possible, avoid using keyless verification and instead rely on pre-configured public keys for signature verification. This eliminates the reliance on the vulnerable subjectRegExp and issuerRegExp fields.
    • Implement Admission Webhooks: Implement custom admission webhooks that perform additional signature validation checks. This can provide an extra layer of security until Kyverno can be upgraded.

Timeline of Discovery and Disclosure

  • 2025-02-24: Issue reported to Kyverno project.
  • 2025-02-24: Patch developed and merged into the Kyverno repository.
  • 2025-03-11: CVE-2025-29778 reserved.
  • 2025-03-24: Kyverno version 1.14.0-alpha.1 released with the fix.
  • 2025-03-24: CVE-2025-29778 publicly disclosed.

References

Read more