GPU VulnDB

Database/Container, Kubernetes & orchestration

aws-privateca-issuer: issuerRef confusion lets a tenant get certificates from a cluster-scoped PCA issuer

CVSS 8.4CVE-2026-119115Container, Kubernetes & orchestrationcurated

Impact

Incorrect authorization in issuer resolution means a certificate request whose issuerRef.kind is missing or wrong can be satisfied by a cluster-scoped AWSPCAClusterIssuer the requester's approval policy does not authorize. An authenticated namespace tenant can therefore obtain certificates - including subordinate CA certificates - signed by the cluster's private CA. A subordinate CA certificate is a key to mint further identities, so on a multi-tenant GPU cluster this breaks the mTLS identity boundary between tenants and between workloads and the control plane: anything trusting that CA chain can be impersonated. Revocation and reissue of anything mis-issued is part of the cleanup, not just the upgrade.

Who can reach it

Any authenticated Kubernetes user or service account that can create CertificateRequest or Certificate resources, or Ingress objects with cert-manager annotations, in a namespace served by the controller. No cluster-admin needed.

What to do

Upgrade aws-privateca-issuer to v1.10.1, or the EKS add-on to v1.10.1-eksbuild.1, and restart the controller deployment. The upgrade is breaking: v1.10.1 requires issuerRef.kind to be exactly AWSPCAIssuer or AWSPCAClusterIssuer and to match the referenced issuer, so every CertificateRequest, Certificate and Ingress annotation with a missing or mismatched kind must be corrected or certificate issuance stops. Audit AWS Private CA issuance logs for certificates that should not have been signed. Controller rollout only - no node drain or reboot.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-119115https://aws.amazon.com/security/security-bulletins/2026-156-aws/https://github.com/cert-manager/aws-privateca-issuer/security/advisories/GHSA-hjrh-q6pg-mh82https://github.com/cert-manager/aws-privateca-issuer/releases/tag/v1.10.1

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.