Skip to content
TrustList
Security advisories

AWS fixes Kubernetes CA connector flaw; check issuer kinds first

Editorial

By TrustList Editorial

CVE-2026-119115 let users limited to a namespace issuer get certificates, even subordinate CAs, from a cluster issuer; v1.10.1 fixes it but stops renewals that lack an exact issuerRef.kind.

About AWS fixes Kubernetes CA connector flaw; check issuer kinds first

AWS fixes Kubernetes CA connector flaw; check issuer kinds first

29 October 2026: AWS has fixed CVE-2026-119115 in its Private CA Connector for Kubernetes, the cert-manager plug-in that signs certificates with AWS Private Certificate Authority. A user whose approval policy only allowed a namespace-scoped issuer could, under certain conditions, get certificates signed by a cluster-scoped issuer instead, including subordinate CA certificates. The fix is aws-privateca-issuer v1.10.1 and EKS add-on v1.10.1-eksbuild.1, and AWS warns that the upgrade will stop some certificates from renewing unless their configuration is corrected first.

Not yet independently verified. Not yet independently verified. This rests on AWS's own bulletin; the GitHub advisory it links could not be opened, and AWS gives no CVSS score. We will update this when it can be confirmed, and remove this note.

What the flaw allowed

cert-manager lets a cluster offer two kinds of issuer: one limited to a namespace, and one available across the cluster. Organisations use the split to keep a team's certificates inside its own namespace and its own CA. The connector's logic for working out which issuer a request referred to was lenient, so a request approved for a namespace issuer could resolve to a cluster issuer. A subordinate CA certificate obtained that way is the serious case, because it can sign further certificates the organisation's PKI would trust.

AWS rates the bulletin Important rather than critical and gives no CVSS score. The attacker has to be an authenticated user who can submit certificate requests.

Before upgrading

v1.10.1 requires issuerRef.kind to be exactly AWSPCAIssuer or AWSPCAClusterIssuer and to match the kind of the issuer it names. After the upgrade:

  • a request with a missing or wrong kind, including kind: Issuer, which cert-manager sets for Ingress annotations that give no issuer kind, is marked Failed;
  • a request with kind: AWSPCAIssuer that points at a cluster-scoped issuer stays Pending indefinitely.

Either way the certificate stops renewing, and the services behind it fail when it expires. AWS's advice is to audit CertificateRequest, Certificate and Ingress resources first and set the kind explicitly: AWSPCAIssuer for namespace-scoped issuers, AWSPCAClusterIssuer for cluster-scoped ones. Teams that run forked or derived versions of the issuer need to carry the fix over themselves.

If the upgrade has to wait

The workaround is to scope certificate approval policies and RBAC rules to both the issuer name and the issuer kind, so an approval for one cannot be used for the other. Where there is any doubt about past requests, a review of certificates issued by cluster-scoped issuers, especially any subordinate CA certificates, shows whether the gap was used.

Sources

Categories & features

TrustList Weekly

The week in software and IT, in one email

The news that matters to buyers, new rankings and our own research. Every Thursday, free, and easy to leave.

We will email you to confirm. Unsubscribe with one click in any issue. Privacy policy