What's Happening?
A critical vulnerability, identified as CVE-2026-119115, has been discovered and addressed in the AWS Private CA Connector for Kubernetes (aws-privateca-issuer). This flaw allowed authenticated users,
whose approval policies were restricted to namespace-scoped issuers, to obtain certificates signed by unauthorized cluster-scoped issuers. The vulnerability could potentially lead to the issuance of subordinate CA certificates, which carry significant security implications. AWS has released fixes in aws-privateca-issuer v1.10.1 and EKS add-on v1.10.1-eksbuild.1. The updated versions enforce a stricter, exact kind-to-scope match for issuer references, meaning that requests relying on previous lenient resolution may fail or remain pending after the upgrade. Users are advised to audit their issuer references before upgrading to prevent service interruptions.
Why It's Important?
This vulnerability is significant because it undermines the intended authorization boundaries within Kubernetes environments utilizing AWS Private CA. In a cloud-native architecture, maintaining strict separation of privileges is paramount. The ability for a namespace-scoped workload to obtain certificates from a cluster-scoped issuer it is not authorized to use creates a potential avenue for privilege escalation and unauthorized access. If exploited, this could allow attackers to sign additional certificates, potentially impersonating services or gaining broader access within the cluster. For organizations relying on AWS Private CA for certificate management in Kubernetes, this fix is crucial for maintaining the integrity and security of their infrastructure, preventing potential breaches, and ensuring compliance with security policies. The need for pre-upgrade auditing highlights the complexity of managing certificate lifecycles in dynamic environments.
What's Next?
Organizations using AWS Private CA Connector for Kubernetes must prioritize upgrading to the fixed versions (v1.10.1 or later for aws-privateca-issuer, and v1.10.1-eksbuild.1 or later for the EKS add-on). Before upgrading, platform teams should conduct a thorough audit of all `issuerRef.kind` values in their `CertificateRequest`, `Certificate`, and `Ingress` resources across all namespaces and clusters. This audit will identify any misconfigurations that might lead to certificate issuance failures post-upgrade. Testing the fixed release in a non-production environment with synthetic identities is recommended to ensure compatibility and proper functioning. After the upgrade, a review of certificates issued during the vulnerable period is advised to identify any unauthorized certificates and take appropriate remediation steps, such as revocation and replacement.
Beyond the Headlines
The incident underscores the intricate security challenges in modern cloud-native environments, where multiple layers of authorization and policy enforcement interact. While Kubernetes RBAC provides a foundational security model, this vulnerability demonstrates that external connectors and their specific implementations can introduce new attack vectors if not meticulously secured. The emphasis on 'exact kind-to-scope match' reflects a broader trend towards more explicit and granular security controls in distributed systems. This event also highlights the importance of continuous security auditing and the need for organizations to have robust incident response plans for certificate-related compromises. The use of synthetic identities in testing is a key takeaway, promoting secure testing practices that avoid exposing sensitive production data while thoroughly validating security fixes.
