CVE-2026-119115 AWS PCA Issuer｜影響と更新前確認

はじめに

2026 年 10 月 29 日（米国太平洋時間）、AWS は AWS Private CA Connector for Kubernetes（aws-privateca-issuer）の認可不備 CVE-2026-119115 を Security Bulletin 2026-156-AWS で公表しました。aws-privateca-issuer は、cert-manager の外部 Issuer として AWS Private CA に証明書の署名を依頼するコンポーネントで、Amazon EKS では EKS add-on としても提供されています。

修正版の v1.10.1 は脆弱性を修正する一方で、証明書要求の issuerRef.kind を厳密に検証するようになりました。従来の緩い解決処理に依存していた Certificate や Ingress は、更新後に証明書の自動更新が止まる可能性があります。脆弱性対応の更新が、証明書の期限切れによる障害の原因にならないよう、更新前の棚卸しが重要です。

結論として、aws-privateca-issuer v1.10.1 未満、または EKS add-on v1.10.1-eksbuild.1 未満を導入している環境は、修正版への更新を推奨します。ただし、v1.10.1 は issuerRef.kind が AWSPCAIssuer または AWSPCAClusterIssuer と完全に一致し、参照先の種類とも一致することを要求するため、更新前に Certificate と Ingress の設定を修正する必要があります。修正せずに更新すると、該当する証明書の更新が止まり、証明書の期限切れ時にサービスへ影響します。

なお、本記事は公開されている一次情報と修正コードに基づく解説であり、筆者による実機検証は行っていません。

CVE-2026-119115 の概要と認可不備

CVE-2026-119115 は、aws-privateca-issuer が証明書要求の参照先 Issuer を解決する処理の認可不備（CWE-863）です。名前空間スコープの Issuer しか承認されていない認証済みの主体が、承認されていないクラスタースコープの Issuer から証明書を取得できる可能性があります。

脆弱性の基本情報

参考: GitHub Security Advisory GHSA-hjrh-q6pg-mh82
“does not correctly enforce the distinction between namespace-scoped and cluster-scoped issuers”
（Issuer 解決処理が、名前空間スコープの Issuer とクラスタースコープの Issuer の区別を正しく適用していません。）
https://github.com/cert-manager/aws-privateca-issuer/security/advisories/GHSA-hjrh-q6pg-mh82

AWSPCAIssuer と AWSPCAClusterIssuer の認可境界

aws-privateca-issuer は 2 種類の Issuer リソースを提供します。どちらも AWS Private CA の CA を参照する点は同じで、違いは参照できる範囲です。

AWSPCAIssuer

名前空間スコープの Issuer です。同じ namespace の Certificate や CertificateRequest から参照され、チームやアプリケーション単位で利用できる CA を分ける用途に使われます。

AWSPCAClusterIssuer

クラスタースコープの Issuer です。名前空間に属さず、すべての namespace から参照できます。共通の CA や、上位の CA を参照する用途で使われることがあります。

cert-manager では、CertificateRequest に Approved 条件が付かない限り、Issuer は署名しません。aws-privateca-issuer も承認済みの要求だけを処理します。承認を行う approver（cert-manager 内部の承認コントローラーや approver-policy など）は、要求の spec.issuerRef（name / kind / group）を基に承認可否を判断します。つまり、承認ポリシーは「どの Issuer を使うか」を要求に書かれた参照先で判断し、その参照先を実際の Issuer へ解決するのは aws-privateca-issuer 側です。

修正前の Issuer 解決処理で起きていたこと

修正コミット（9ae225b）の差分によると、修正前の Issuer 解決処理は、まず要求と同じ namespace から AWSPCAIssuer を名前で検索し、見つからない場合は同じ名前の AWSPCAClusterIssuer を検索していました。kind の値は、AWSPCAClusterIssuer の場合に namespace を外す判定にしか使われていませんでした。

この結果、承認側は「名前空間スコープの Issuer への要求」として承認したにもかかわらず、実際にはクラスタースコープの Issuer が署名する、という承認内容と実行内容のずれが生じ得ました。修正版では、kind が指定した種類のリソースだけを検索します。

参考: aws-privateca-issuer 修正コミット 9ae225b
“the lookup now follows issuerRef.kind”
（Issuer の検索は issuerRef.kind に従うようになりました。）
https://github.com/cert-manager/aws-privateca-issuer/commit/9ae225b69557023025040845ab5f157b88815a94

下位 CA 証明書が影響に含まれる意味と、影響の範囲

AWS は、取得し得る証明書に下位 CA 証明書が含まれると説明しています。下位 CA 証明書と秘密鍵を不正に入手した主体は、その CA を信頼するクライアントに対して有効な証明書を自ら発行できる可能性があります。これは個別のサーバー証明書の不正取得より影響範囲が広くなり得るため、CVSS で完全性（I）が High と評価されている点と整合します。

ただし、下位 CA 証明書を実際に発行できるかは環境に依存します。aws-privateca-issuer は要求の用途や Issuer の spec.pcaTemplate 設定に応じて AWS Private CA の証明書テンプレートを選択するため、クラスタースコープ Issuer の設定や AWS Private CA 側の構成によって結果は異なります（編集上の整理）。また、次の点も区別して判断してください。

• 認証不要の攻撃ではなく、証明書要求を作成できる認証済み主体による条件付きの認可不備です。
• AWS Private CA サービス自体の侵害ではなく、クラスター内で動作する Issuer コンポーネントの不備です。
• 公表資料に悪用事例の記載はありませんが、悪用が存在しないことを示すものではありません。

影響する環境と修正版

影響を受けるのは、aws-privateca-issuer を導入しているクラスターです。cert-manager を使っていても、aws-privateca-issuer を導入していない環境は対象外です。提供形態ごとの影響範囲と修正版は次のとおりです。

Helm 等で管理している環境と EKS add-on では、バージョンの確認方法と更新手順が異なります。EKS add-on の名前空間は aws-privateca-issuer です。AWS は、Fork や派生コードを利用している場合も修正内容を取り込むよう求めています。サードパーティーが再パッケージしたイメージを使っている場合は、提供元のアドバイザリで修正の取り込み状況を確認してください。

参考: AWS Security Bulletin 2026-156-AWS
“v1.10.1 enforces that issuerRef.kind is exactly AWSPCAIssuer or AWSPCAClusterIssuer”
（v1.10.1 は、issuerRef.kind が AWSPCAIssuer または AWSPCAClusterIssuer と完全に一致することを強制します。）
https://aws.amazon.com/security/security-bulletins/2026-156-aws/

更新前に確認する Issuer と証明書設定

更新前に、影響判定と互換性問題の洗い出しを読み取り専用のコマンドで行います。このセクションのコマンドはいずれもリソースを変更しません。<cluster-name> などの山括弧は環境に合わせて置き換えてください。

aws eks describe-addon --cluster-name <cluster-name> --addon-name aws-privateca-connector-for-kubernetes --query 'addon.addonVersion' --output text

helm list -A

kubectl get deploy -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,IMAGE:.spec.template.spec.containers[*].image' | grep -i privateca

kubectl get awspcaissuers -A
kubectl get awspcaclusterissuers

kubectl get awspcaissuers -A -o json > awspcaissuers.json
kubectl get awspcaclusterissuers -o json > awspcaclusterissuers.json
kubectl get certificates -A -o json > certificates.json
kubectl get ingress -A -o json > ingresses.json

kubectl get certificaterequests -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,ISSUER:.spec.issuerRef.name,KIND:.spec.issuerRef.kind,GROUP:.spec.issuerRef.group,READY:.status.conditions[?(@.type=="Ready")].reason'

($ns[0].items | map("\(.metadata.namespace)/\(.metadata.name)")) as $nsi
| ($cl[0].items | map(.metadata.name)) as $cli
| .items[]
| (.spec.issuerRef.name // "") as $n
| (.spec.issuerRef.kind // "") as $k
| (.spec.issuerRef.group // "") as $g
| "\(.metadata.namespace)/\($n)" as $key
| ($nsi | index($key)) as $hasNs
| ($cli | index($n)) as $hasCl
| (if $g == "awspca.cert-manager.io" then
     (if $k == "AWSPCAIssuer" then (if $hasNs != null then "OK" elif $hasCl != null then "PENDING_RISK" else "NOT_FOUND" end)
      elif $k == "AWSPCAClusterIssuer" then (if $hasCl != null then "OK" else "NOT_FOUND" end)
      else "FAILED_RISK" end)
   elif ($k == "AWSPCAIssuer" or $k == "AWSPCAClusterIssuer" or $hasNs != null or $hasCl != null) then "CHECK_GROUP"
   else "OTHER" end) as $r
| [$r, .metadata.namespace, .metadata.name, $n, (if $k == "" then "(none)" else $k end), (if $g == "" then "(none)" else $g end)]
| @tsv

jq -r --slurpfile ns awspcaissuers.json --slurpfile cl awspcaclusterissuers.json -f check-certificates.jq certificates.json

($ns[0].items | map("\(.metadata.namespace)/\(.metadata.name)")) as $nsi
| ($cl[0].items | map(.metadata.name)) as $cli
| .items[]
| (.metadata.annotations // {}) as $a
| select($a | to_entries | any(.key | startswith("cert-manager.io/")))
| ($a["cert-manager.io/issuer"] // "") as $n
| ($a["cert-manager.io/cluster-issuer"] // "") as $c
| ($a["cert-manager.io/issuer-kind"] // "") as $k
| ($a["cert-manager.io/issuer-group"] // "") as $g
| "\(.metadata.namespace)/\($n)" as $key
| ($nsi | index($key)) as $hasNs
| ($cli | index($n)) as $hasCl
| (if $c != "" and ($cli | index($c)) != null then "CHECK_CLUSTER_ISSUER"
   elif $g == "awspca.cert-manager.io" then
     (if $k == "AWSPCAIssuer" then (if $hasNs != null then "OK" elif $hasCl != null then "PENDING_RISK" else "NOT_FOUND" end)
      elif $k == "AWSPCAClusterIssuer" then (if $hasCl != null then "OK" else "NOT_FOUND" end)
      else "FAILED_RISK" end)
   elif $n != "" and ($k == "AWSPCAIssuer" or $k == "AWSPCAClusterIssuer" or $hasNs != null or $hasCl != null) then "CHECK_GROUP"
   else "OTHER" end) as $r
| [$r, .metadata.namespace, .metadata.name, (if $n == "" then "-" else $n end), (if $c == "" then "-" else $c end), (if $k == "" then "(none)" else $k end), (if $g == "" then "(none)" else $g end)]
| @tsv

jq -r --slurpfile ns awspcaissuers.json --slurpfile cl awspcaclusterissuers.json -f check-ingresses.jq ingresses.json

kubectl get secrets -A --field-selector type=kubernetes.io/tls -o json | jq -r '.items[] | select(.metadata.annotations["cert-manager.io/issuer-group"] == "awspca.cert-manager.io") | [.metadata.namespace, .metadata.name, (.metadata.annotations["cert-manager.io/certificate-name"] // "-"), (.metadata.annotations["cert-manager.io/issuer-kind"] // "(none)"), (.metadata.annotations["cert-manager.io/issuer-name"] // "-")] | @tsv'

kubectl get clusterroles -o json | jq -r '.items[] | select(any(.rules[]?; (.resources // [] | index("signers")) and (.verbs // [] | index("approve")))) | .metadata.name'

kubectl get certificaterequestpolicies -o yaml

helm get values <cert-manager-release> -n <cert-manager-namespace>

jq -r '[.items[] | select(.spec.issuerRef.group == "awspca.cert-manager.io" or .spec.issuerRef.kind == "AWSPCAIssuer" or .spec.issuerRef.kind == "AWSPCAClusterIssuer")] | sort_by([(.status.renewalTime == null), .status.renewalTime]) | .[] | [.metadata.namespace, .metadata.name, (.spec.issuerRef.kind // "(none)"), (.status.renewalTime // "(未設定)"), (.status.notAfter // "(未設定)")] | @tsv' certificates.json

v1.10.1 更新時の issuerRef.kind の注意点

修正版では、issuerRef.kind が参照先 Issuer の種類と一致しない要求は処理されません。AWS は、従来の緩い解決処理に依存していた証明書要求は更新後に renewal が止まり、その証明書に依存するサービスは証明書の期限切れ時に影響を受けると説明しています。

修正版で変わる判定

修正版の列は AWS Bulletin と GHSA の説明、修正前の列は修正コミットの差分から読み取れる挙動を整理したものです。修正版のコードでは、Failed の場合は unsupported issuer kind、Pending の場合は issuer could not be found というメッセージが CertificateRequest の Ready 条件に設定されます。

Ingress 注釈で kind を省略した場合の既定値

Ingress の cert-manager.io/issuer 注釈は、kind を指定しない場合に cert-manager の Issuer を参照する前提で Certificate を生成します。AWS は、Ingress 注釈で issuer kind を指定しない場合に cert-manager が設定する kind: Issuer も、修正版では Failed になると明記しています。

参考: cert-manager Documentation（Annotated Ingress resource）
“It will default to cert-manager.io Issuer”
（cert-manager.io の Issuer が既定値になります。）
https://cert-manager.io/docs/usage/ingress/

aws-privateca-issuer を Ingress から使う場合は、名前空間スコープ、クラスタースコープのどちらでも cert-manager.io/issuer に Issuer 名を指定し、cert-manager.io/issuer-kind と cert-manager.io/issuer-group を併記します。cert-manager.io/cluster-issuer は cert-manager 自身の ClusterIssuer 用の短縮指定であり、AWSPCAClusterIssuer の指定には使えません。AWSPCAClusterIssuer を参照する場合の例は次のとおりです。

metadata:
  annotations:
    cert-manager.io/issuer: example-cluster-issuer
    cert-manager.io/issuer-kind: AWSPCAClusterIssuer
    cert-manager.io/issuer-group: awspca.cert-manager.io

Certificate を直接定義している場合は、issuerRef に kind と group を明示します。名前空間スコープの Issuer を参照する場合は、kind を AWSPCAIssuer にし、同じ namespace に同名の AWSPCAIssuer があることを確認します。

spec:
  issuerRef:
    name: example-cluster-issuer
    kind: AWSPCAClusterIssuer
    group: awspca.cert-manager.io

CertificateRequest は直接編集しない

Failed や Pending になった CertificateRequest の issuerRef を書き換えて回避することはできません。CertificateRequest は一度きりの要求を表すリソースで、spec は作成後に変更できません。

参考: cert-manager Documentation（CertificateRequest resource）
“are immutable and cannot be modified after creation”
（作成後は変更できない、不変のフィールドです。）
https://cert-manager.io/docs/usage/certificaterequest/

修正は、CertificateRequest を生成している設定元に対して行います。Ingress から生成された Certificate は ingress-shim が Ingress の注釈に合わせて管理するため、Certificate ではなく Ingress の注釈を修正します。直接定義した Certificate は、その issuerRef を修正します。修正した設定は、次回の更新時に新しい CertificateRequest へ反映されます。次回更新を待たずに確認したい場合は cmctl renew <certificate-name> -n <namespace> で再発行を手動で開始でき、cert-manager が新しい CertificateRequest を作成します。

Argo CD や Flux などで Kubernetes マニフェストを管理している場合は、Git 上のマニフェストや Helm 値を修正してください。クラスター上のリソースだけを直接修正すると、同期時に元の設定へ戻され、更新後に再び発行が止まる可能性があります。

更新を安全に進める順序

正しい kind の指定は修正前のバージョンでも受け付けられるため、設定の修正を先に済ませてから修正版へ更新すると、互換性問題と脆弱性対応を切り分けられます（編集上の推奨）。全証明書を更新前に再発行する必要はありません。棚卸しと設定修正は対象を絞って短期間で済ませ、修正版の適用を不必要に遅らせないことを推奨します。

aws eks describe-addon-versions --addon-name aws-privateca-connector-for-kubernetes --query 'addons[].addonVersions[].addonVersion'

aws eks update-addon --cluster-name <cluster-name> --addon-name aws-privateca-connector-for-kubernetes --addon-version v1.10.1-eksbuild.1

helm repo update
helm search repo awspca/aws-privateca-issuer --versions

helm upgrade <release> awspca/aws-privateca-issuer -n <namespace> --version <chart-version> -f <current-values.yaml>

更新後の確認と暫定対策

更新後は、新しい証明書要求が正しい Issuer で処理されること、既存の証明書が次回更新でも Ready を維持できることを確認します。すぐに更新できない環境では、承認ポリシーと RBAC の範囲を絞る暫定対策を検討します。

更新後に確認する項目

まず、CertificateRequest の Ready 条件の理由とメッセージを確認し、unsupported issuer kind（Failed）や issuer could not be found（Pending）が出ていないかを確認します。REASON が <none> の行は Ready 条件がまだ設定されていない要求で、承認待ちなどで処理が進んでいない可能性があるため、あわせて確認します。

kubectl get certificaterequests -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,KIND:.spec.issuerRef.kind,REASON:.status.conditions[?(@.type=="Ready")].reason,MESSAGE:.status.conditions[?(@.type=="Ready")].message'

次に、Ready が True でない Certificate と、Ready 条件そのものが設定されていない Certificate を抽出します。自動更新に失敗した証明書や、発行処理が始まっていない証明書もここで検出できます。

kubectl get certificates -A -o json | jq -r '.items[] | ([.status.conditions[]? | select(.type == "Ready")] | .[0]) as $c | select($c == null or $c.status != "True") | [.metadata.namespace, .metadata.name, (.spec.issuerRef.kind // "(none)"), (if $c == null then "(Ready 条件なし)" else ($c.status + " " + ($c.reason // "")) end)] | @tsv'

個別の証明書は cmctl status certificate で、関連する CertificateRequest、Secret、Issuer の状態とイベントをまとめて確認できます。

cmctl status certificate <certificate-name> -n <namespace>

controller のログでは、更新後に Issuer の解決に失敗していないかを確認します。Deployment 名は導入方法によって異なるため、kubectl get deploy -n <namespace> で確認してから指定してください。

kubectl logs -n <issuer-namespace> deploy/<issuer-deployment> --since=1h

kubectl logs -n <cert-manager-namespace> deploy/<cert-manager-deployment> --since=1h

最後に、アプリケーション側で新しい証明書が使われていることを TLS 接続で確認します。発行元と有効期限が想定どおりかを確認してください。

openssl s_client -connect <host>:443 -servername <host> </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

更新直後に問題がなくても、kind の誤りは次回更新のタイミングで表面化します。棚卸しの手順 8 で確認した renewalTime の近い証明書から、更新後の初回 renewal が成功したかを追跡することを推奨します。継続的な監視には、cert-manager の Prometheus メトリクスの活用も検討できます。

すぐに更新できない場合の暫定対策

AWS は、すぐに更新できない場合の回避策として、証明書の承認ポリシーと RBAC ルールを Issuer の名前と kind の両方で絞ることを挙げています。具体的には次の点を確認します。

• approver-policy の selector.issuerRef で name、kind、group を完全一致で指定し、kind の省略や *Issuer のようなワイルドカードを避けます。
• approve 権限の resourceNames は、名前空間スコープ Issuer なら awspcaissuers.awspca.cert-manager.io/<namespace>.<name>、クラスタースコープ Issuer なら awspcaclusterissuers.awspca.cert-manager.io/<name> の形式で個別に指定し、/* による一括許可を必要最小限にします。
• 下位 CA 証明書を発行する必要がない要求には、approver-policy の allowed で isCA: false（または未指定）とし、CA 証明書の要求を承認しないようにします。

参考: cert-manager Documentation（approver-policy API Reference）
“An omitted field matches all kinds.”
（kind を省略すると、すべての kind に一致します。）
https://cert-manager.io/docs/policy/approval/approver-policy/api-reference/

名前、kind、group を限定した CertificateRequestPolicy の例は次のとおりです。approver-policy の allowed は、省略した項目を「許可しない」と扱うため、実際の要求に含まれる DNS 名や用途に合わせて調整が必要です（approver-policy の公式ドキュメント）。

apiVersion: policy.cert-manager.io/v1alpha1
kind: CertificateRequestPolicy
metadata:
  name: team-a-awspca
spec:
  allowed:
    isCA: false
    dnsNames:
      values:
      - "*.team-a.example.com"
    usages:
    - "digital signature"
    - "key encipherment"
    - "server auth"
  selector:
    issuerRef:
      name: "team-a-issuer"
      kind: "AWSPCAIssuer"
      group: "awspca.cert-manager.io"
    namespace:
      matchNames:
      - "team-a"

このポリシーは作成するだけでは評価されません。approver-policy は、selector に一致し、かつ要求の作成主体が RBAC でポリシーの use 権限を持つ場合にだけ、そのポリシーで要求を評価します。前提として、cert-manager 本体の自動承認を無効化し、approver-policy が aws-privateca-issuer の signer を承認対象にするよう設定されている必要があります。ポリシーをバインドする例は次のとおりです。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cert-manager-policy:team-a-awspca
rules:
- apiGroups: ["policy.cert-manager.io"]
  resources: ["certificaterequestpolicies"]
  verbs: ["use"]
  resourceNames: ["team-a-awspca"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cert-manager-policy:team-a-awspca
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cert-manager-policy:team-a-awspca
subjects:
- kind: ServiceAccount
  name: <cert-manager-serviceaccount>
  namespace: <cert-manager-namespace>

Certificate から生成される CertificateRequest の作成主体は、利用者ではなく cert-manager コントローラーの ServiceAccount です。そのため、Certificate 経由の要求を対象にする場合は cert-manager の ServiceAccount をバインドします。この場合、バインドだけでは namespace ごとの利用者を区別できないため、例のように selector の namespace や issuerRef で対象を絞ることが重要です。CertificateRequest を利用者が直接作成する運用では、その利用者や ServiceAccount をバインドします。

ただし、修正前の実装は、kind が AWSPCAIssuer の要求でも、対象 namespace に同名の AWSPCAIssuer が存在しない場合は同名の AWSPCAClusterIssuer へフォールバックします。問題は名前が同じこと自体ではなく、名前空間スコープ Issuer が見つからないときにクラスタースコープ Issuer で解決されてしまう処理です。そのため、ポリシーで kind を限定するだけでは防げない経路が残ります。承認対象とする AWSPCAIssuer が各 namespace に実在するかを確認し、実在しない名前への要求が意図しない AWSPCAClusterIssuer に解決され得ないかを、AWSPCAClusterIssuer の一覧と照合してください（修正コミットの差分に基づく編集上の推論）。棚卸しの手順 4、5 で PENDING_RISK と判定された設定が、この経路に該当します。いずれの暫定対策も修正版への更新を代替するものではありません。

標準の Kubernetes RBAC で制御できるのは、誰が Certificate や CertificateRequest を作成できるか、誰が承認できるかまでです。要求の issuerRef にどの name や kind を書けるかといった内容の検査は、cert-manager の承認の仕組み（approver-policy など）の役割です。両者を組み合わせて、要求できる主体と承認される内容の両方を絞ってください。

まとめ

CVE-2026-119115 は、aws-privateca-issuer が issuerRef.kind を無視して Issuer を解決していたことによる認可不備です。修正版への更新は必要ですが、同じ修正が kind の厳密な検証を導入するため、更新前の設定確認と修正が対応の中心になります。

• 影響は aws-privateca-issuer v1.10.1 未満と EKS add-on v1.10.1-eksbuild.1 未満です。
• 認証済み主体が承認外のクラスタースコープ Issuer を使える可能性があります。
• 下位 CA 証明書の発行可否は Issuer と CA の構成に依存します。
• 修正版では kind の誤りや省略が Failed、種類の不一致が Pending になります。
• Ingress は issuer-kind と issuer-group の注釈を明示する必要があります。
• CertificateRequest は編集せず、Certificate や Ingress などの設定元を修正します。
• 更新後は次回 renewal まで追跡し、自動更新の失敗を早期に検出します。

以上、最後までお読みいただきありがとうございました。