CloudNativePGの重大な脆弱性 CVE-2026-44477、Kubernetes上のPostgreSQLで権限昇格とPod内RCEの恐れ|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年05月18日更新日時: 2026年05月18日

CloudNativePGに、PostgreSQLのスーパーユーザー権限昇格とKubernetes Pod内でのリモートコード実行につながる重大な脆弱性CVE-2026-44477が公開されました。今回の脆弱性は、監視用のmetrics exporterがPostgreSQLへ接続する際の権限処理に起因します。

CloudNativePGの公式リリースでは、CVE-2026-44477はCVSS v4.0で9.4のCriticalとして扱われています。影響を受けるのは、CloudNativePG 1.28.3より前のバージョン、および1.29.0です。修正版として1.28.3と1.29.1が公開されています。

1 何が起きたか
2 影響範囲
3 原因
4 Kubernetesとの関連
5 情報システム部門が確認すべきポイント
6 監視で確認すべきポイント
7 出典

何が起きたか

問題は、metrics exporterがPostgreSQLへ接続する際、内部的にpostgresスーパーユーザーとして接続し、その後にSET ROLE pg_monitorで権限を落としていた点にあります。この処理では、現在のユーザーはpg_monitorに変わるものの、セッション上の元のユーザーはpostgresのまま残ります。

そのため、メトリクス取得時に評価されるSQL式の中で権限を戻すことができる場合、攻撃者はPostgreSQLスーパーユーザー権限を取り戻し、さらにPostgreSQLの機能を悪用してPod内でOSプロセスを起動できる可能性があります。

影響範囲

GitHub Advisoryでは、

影響を受けるバージョンはCloudNativePG 1.28.3未満、および1.29.0
修正済みバージョンは1.28.3および1.29.1です。

CloudNativePGの公式リリースでは、脆弱性の影響として、低権限のPostgreSQLロールからPostgreSQLスーパーユーザー権限への昇格、およびprimary Pod内でpostgresユーザーとして任意のOSプロセスを実行できる可能性が示されています。

影響が大きくなるのは、Kubernetes上でCloudNativePGを使ってPostgreSQLを運用している環境です。特に、アプリケーションごとにデータベースを提供している基盤、社内PaaS、SaaS基盤、マルチテナント型の開発環境では、低権限のデータベースユーザーが存在することが多く、影響を慎重に評価する必要があります。

また、カスタムメトリクスを利用している環境も注意が必要です。メトリクスクエリの中にスキーマ修飾されていない関数やビュー、テーブル参照が含まれている場合、検索パスやオブジェクト名の衝突を悪用される可能性があります。

さらに、アプリケーション側にSQLインジェクションが存在する環境では、データベースユーザーの権限が低くても、CloudNativePGの監視経路を踏み台にしてPod内RCEへつながる可能性があります。これは、データベース侵害がKubernetes Podの侵害へ拡大し得るという意味で危険です。

原因

原因は、CloudNativePGのmetrics exporterがPostgreSQLへ接続する際の権限分離が不十分だったことです。

metrics exporterは、PodローカルのUnixソケット経由でpostgresスーパーユーザーとして接続し、その後にpg_monitorロールへ切り替えていました。しかし、SET ROLEではcurrent_userは変更されてもsession_userはpostgresのまま残ります。

この状態では、メトリクス取得時に評価されるSQLの中で権限を戻すことができ、結果としてスーパーユーザー権限を再取得できる余地が生まれます。

CloudNativePGの公式説明では、悪用経路は大きく2つ示されています。

1つ目は、カスタムメトリクスのクエリにスキーマ修飾されていない関数やリレーション参照が含まれる場合です。攻撃者が検索パス上に同名のオブジェクトを作成できると、メトリクス取得時に意図しないオブジェクトが評価される可能性があります。

2つ目は、カスタムメトリクスを使っていない標準構成でも成立し得る経路です。公式リリースでは、出荷時のpg_extensionsメトリクスが、標準デプロイでも攻撃チェーンを成立させる条件になり得たと説明されています。

つまり、カスタム監視を使っている環境だけが危険というわけではありません。標準設定に近いCloudNativePG環境でも、低権限ユーザーからスーパーユーザー権限昇格へつながる可能性があった点が重要です。

Kubernetesとの関連

CVE-2026-44477で重要なのは、単なるPostgreSQL内部の権限昇格にとどまらず、Kubernetes上で動作するPostgreSQL Pod内のOSコマンド実行につながる可能性がある点です。

CloudNativePGは、Kubernetes上でPostgreSQLクラスタを管理するためのオペレーターです。PostgreSQLのprimary、replica、バックアップ、フェイルオーバー、監視などをKubernetesのリソースとして扱い、Pod単位でPostgreSQLを運用します。そのため、CloudNativePGの脆弱性は、データベースだけでなく、Kubernetes上のワークロード運用にも影響します。

今回の脆弱性では、低権限のPostgreSQLユーザーがmetrics exporterの処理を悪用し、PostgreSQLスーパーユーザー権限へ昇格できる可能性があります。さらに、PostgreSQLスーパーユーザー権限を得た攻撃者は、PostgreSQLの機能を悪用してprimary Pod内でOSプロセスを実行できる可能性があります。

ただし、この脆弱性だけで直ちにKubernetesクラスタ全体が乗っ取られると断定すべきではありません。公開情報で示されている影響は、primary Pod内でpostgresユーザーとして任意のOSプロセスを実行できる可能性です。ノード全体の制御、Kubernetes APIの管理者権限取得、他Namespaceへの侵害が自動的に成立するわけではありません。

一方で、Pod内でコード実行が可能になることは軽視できません。Pod内には、環境変数、マウントされたSecret、ConfigMap、サービスアカウントトークン、バックアップ用認証情報、クラウドストレージの接続情報などが存在する場合があります。これらが過剰に付与されていると、Pod内RCEを起点に、Kubernetes APIへのアクセス、クラウドリソースへのアクセス、他システムへの横展開につながる可能性があります。

特に、CloudNativePGのPodに不要なKubernetes権限が付与されている環境、サービスアカウントトークンの自動マウントを許可している環境、Namespace間の通信制限がない環境、Secretを広くマウントしている環境では、影響が拡大しやすくなります。

そのため、今回の対応ではCloudNativePGのアップグレードだけでなく、Kubernetes側の権限設計も確認する必要があります。CloudNativePGのPodに付与されているServiceAccount、Role、ClusterRole、RoleBinding、ClusterRoleBindingを確認し、必要最小限の権限になっているかを見直してください。

また、NetworkPolicyでPostgreSQL Podから不要な外部通信やNamespace間通信を制限しているかも重要です。攻撃者がPod内でコード実行できた場合でも、外部への通信や他サービスへの到達を制限できれば、被害拡大を抑えられます。

Kubernetes環境では、データベースをPodとして動かすことで運用の自動化や可用性向上が可能になります。一方で、データベース内部の権限昇格がPod内RCEへつながると、アプリケーション層、データベース層、Kubernetes基盤層の境界が曖昧になります。今回のCVE-2026-44477は、Kubernetes上のデータベース運用において、オペレーター、監視エクスポーター、ServiceAccount、Secret、NetworkPolicyを一体で管理する必要があることを示しています。

情報システム部門が確認すべきポイント

まず、Kubernetes環境でCloudNativePGを利用しているかを確認してください。利用している場合は、オペレーターのバージョンが1.28.3未満、または1.29.0ではないかを確認します。

次

監視で確認すべきポイント

パッチ適用と並行して、影響を受ける可能性のあるクラスタで不審な挙動がないかを確認してください。

PostgreSQL側では、低権限ユーザーによる不自然なスキーマ作成、関数作成、ビュー作成、search_pathの変更、拡張機能関連の操作を確認します。特に、監視メトリクスで参照される名前と同名のオブジェクトがユーザー定義スキーマに作成されていないかを確認してください。

Kubernetes側では、CloudNativePG管理下のprimary Podで不審なプロセスが起動していないか、通常とは異なる外部通信がないか、Pod内に不審なファイルが作成されていないかを確認します。

また、監視基盤側のログも重要です。Prometheusなどのスクレイプ間隔に合わせて、PostgreSQL側で異常なクエリや関数実行が発生していないかを確認してください。今回の脆弱性では、メトリクス取得のタイミングが攻撃チェーンに関係するため、通常のアプリケーションログだけでは痕跡を見落とす可能性があります。