aws-privateca-issuer EUVD-2026-113218

Requires a Kubernetes cluster running aws-privateca-issuer before v1.10.1 (or the EKS add-on before v1.10.1-eksbuild.1) that defines at least one cluster-scoped AWSPCAClusterIssuer alongside namespace-scoped AWSPCAIssuer resources. The attacker must be an authenticated user whose approval policy/RBAC authorizes only a namespace-scoped issuer, and must submit a CertificateRequest, Certificate, or Ingress whose issuerRef.kind is missing, incorrect, or does not match the referenced issuer (including the cert-manager default kind: Issuer on unspecified Ingress annotations) - the pre-fix lenient resolution then binds it to the unauthorized cluster-scoped issuer. Limiting factors: exploitation is impossible without an existing cluster-scoped issuer to target, requires valid authenticated cluster credentials with namespace certificate-approval rights (not unauthenticated), and is fully neutralized by scoping approval policies/RBAC to both issuer name and kind, or by upgrading to v1.10.1.

The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scoring 8.4 indicates a network-reachable, low-complexity flaw requiring low privileges and no user interaction, with high integrity impact on the vulnerable system (VI:H) and a subsequent-system integrity impact (SI:H) reflecting the compromise of PKI trust when unauthorized certificates - including subordinate CA certificates - are issued. The signals partly temper the raw score: PR:L means exploitation is NOT unauthenticated - the attacker must already be an authenticated Kubernetes user holding namespace-scoped certificate approval, and a cluster-scoped AWSPCAClusterIssuer must exist in the cluster for there to be anything to escalate to. There is no KEV listing (not confirmed actively exploited), no public exploit identified at time of analysis, and no EPSS score was provided in the input, so widespread opportunistic exploitation cannot be inferred. The vuln.today decision label is 'this_week', consistent with a serious authorization flaw that is patched but gated behind existing cluster access. Net assessment: a genuine privilege/authorization escalation worth prioritizing on the vendor's this-week cadence, but its blast radius is bounded by the need for pre-existing authenticated namespace access and a specific issuer topology, so it is not an internet-wide unauthenticated emergency. EPSS data is missing and should be checked to refine likelihood.

An authenticated Kubernetes user who only holds certificate-approval rights for a namespace-scoped issuer submits a CertificateRequest (or Certificate/Ingress) with a missing, incorrect, or non-matching issuerRef.kind, and the pre-v1.10.1 lenient issuer resolution logic resolves it to a cluster-scoped AWSPCAClusterIssuer they are not authorized to use. The result is that AWS Private CA signs a certificate - potentially a subordinate CA certificate - on their behalf, granting trust they should not have. No public exploit identified at time of analysis; the attack requires existing authenticated access per CVSS PR:L.