Most recent entries from all

BIT-kyverno-2025-29778 — Kyverno ignores subjectRegExp and IssuerRegExp

2026-10-03T01:23:42.991835+00:00

Affected: Bitnami: kyverno

Kyverno is a policy engine designed for cloud native platform engineering teams. Prior to version 1.14.0, Kyverno ignores subjectRegExp and IssuerRegExp while verifying artifact's sign with keyless mode. It allows the attacker to deploy kubernetes resources with the artifacts that were signed by unexpected certificate. Deploying these unauthorized kubernetes resources can lead to full compromise of kubernetes cluster. Version 1.14.0 contains a patch for the issue.

EUVD-2026-224588

2026-10-03T01:23:42.991887+00:00

EUVD-2026-224588

fkie_cve-2025-29778

2026-10-03T01:23:42.991903+00:00

Kyverno is a policy engine designed for cloud native platform engineering teams. Prior to version 1.14.0-alpha.1, Kyverno ignores subjectRegExp and IssuerRegExp while verifying artifact's sign with keyless mode. It allows the attacker to deploy kubernetes resources with the artifacts that were signed by unexpected certificate. Deploying these unauthorized kubernetes resources can lead to full compromise of kubernetes cluster. Version 1.14.0-alpha.1 contains a patch for the issue.

GHSA-46mp-8w32-6g94 — Kyverno ignores subjectRegExp and IssuerRegExp

2026-10-03T01:23:42.991928+00:00

Affected: Go: github.com/kyverno/kyverno

### Summary Kyverno ignores subjectRegExp and IssuerRegExp while verifying artifact's sign with keyless mode. It allows the attacker to deploy kubernetes resources with the artifacts that were signed by unexpected certificate.

### Details Kyverno checks only subject and issuer fields when verifying an artifact's signature: https://github.com/Mohdcode/kyverno/blob/373f942ea9fa8b63140d0eb0e101b9a5f71033f3/pkg/cosign/cosign.go#L537. While there are subjectRegExp and issuerRegExp fields that can also be used for the defining expected subject and issue values. If the last ones are used then their values are not taken in count and there is no actually restriction for the certificate that was used for the image sign.

### PoC

For the successful exploitation attacker needs: - Private key of any certificate in the certificate chain that trusted by cosign. It can be certificate that signed by company's self-signed Root CA if they are using their own PKI. - Access to container registry to push artifacts images - Availability to deploy malicious artifacts to the kubernetes cluster

1. Generate certificate that will be used for the image signing with the oidcissuer url. That can be done with the Fulcio or manually by using openssl

``` # Create self-signed RootCA openssl req -x509 -newkey rsa:4096 -keyout root-ca-key.pem -sha256 -noenc -days 9999 -subj "/C=AA/L=Location/O=IT/OU=Security/CN=Root Certificate Authority" -out root-ca.pem

# Create request for the intermediate certificat…

openSUSE-SU-2025:14937-1 — govulncheck-vulndb-0.0.20250327T184518-1.1 on GA media

2026-10-03T01:23:42.991984+00:00

govulncheck-vulndb-0.0.20250327T184518-1.1 on GA media