PostgreSQL 脆弱性 CVE-2026-6460｜22年前の型の取り違えでコード実行、52件の修正と確認手順

PostgreSQL の脆弱性 CVE-2026-6460 などを直すため、PostgreSQL は2026年11月12日、サポート中のすべての版の更新（18.7・17.12・16.16・15.20・14.25）を出し、52件の脆弱性と140件超の不具合を直した。 中でも CVE-2026-6460（CVSS 8.8）は、ALTER … SET DATA TYPE などで型を変えたあとに古い型の値が残る「型の取り違え」で、オブジェクトを作れる認証済みユーザーが、データベースを動かす OS ユーザーとして任意のコードを実行できる。発見者の1人の Mehmet Ince 氏は、原因の仕組みが2004年からあったと書き、PostgreSQL 18.6 でサーバーのシェルを取る実演を公開した。

まず、動いているサーバーの版を確かめる。psql で次のクエリを実行すると、修正済みかどうかを返す。

SELECT current_setting('server_version') AS version,
  CASE
    WHEN v >= 190000 THEN '19系：RC 2 以降か確かめる'
    WHEN v >= 180007 THEN '修正済み'
    WHEN v BETWEEN 170012 AND 179999 THEN '修正済み'
    WHEN v BETWEEN 160016 AND 169999 THEN '修正済み'
    WHEN v BETWEEN 150020 AND 159999 THEN '修正済み'
    WHEN v BETWEEN 140025 AND 149999 THEN '修正済み（14は今回で保守終了）'
    ELSE '要更新'
  END AS status
FROM (SELECT current_setting('server_version_num')::int AS v) s;

まずやること

・自分でサーバーを運用している：上のクエリで「要更新」なら、修正済みのバージョンに上げる。すぐに上げられなければ、下の「対策」の2で作成権限を絞る
・マネージドサービス（RDS・Azure・Cloud SQL・Supabase など）を使っている：自分ではバイナリを入れ替えられない。事業者の告知と、マイナーバージョンの更新の予定を確かめる
・運用端末や CI で pg_dump・pg_restore を使っている：クライアントのパッケージも更新する。他人から受け取ったダンプは、更新前の pg_restore で戻さない

PostgreSQL まわりの脆弱性では、管理ツールの pgAdmin 脆弱性 CVE-2026-116241｜Import/ExportのOSコマンドインジェクション も10月に出ている。依存先の脆弱性を含めた守り方の全体像は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 にまとめた。

CVE-2026-6460 の時系列

CVE-2026-6460 は、PostgreSQL が「傘」として扱った修正だ。発見者によると、同じ根の問題として21件を報告し、52件のうち6件がこの研究に直接つながる（CVE-2026-6460、120142、120148、116329、116306、120139）。修正のコミットには14人の報告者の名前があり、OpenAI のセキュリティ研究チームや Anthropic の研究者も含まれる。発見者は、自分はサイバー攻撃向けの AI モデルを使わずにたどり着いたと書き、AI の時代の脆弱性研究では同じ弱点に複数の道からたどり着くことがあると述べている。

何が起きたか：型を変えたあとに古い値が残る

PostgreSQL の値は、自分がどの型かを持っていない。型の情報は別の場所（データ辞書）にあり、値はそれに従って読まれる。公式の説明では、型を変えたあとも古い型の値が、データ辞書の項目、PL/pgSQL の変数など、システムのあちこちに残りえた。

発見者の実演の流れはこうだ。一時オブジェクト用のスキーマ（pg_temp）に、項目が1つの複合型を作る。その型を使うクエリを準備（PREPARE）してから、項目の型を変え、準備したクエリを実行する。すると PostgreSQL は、古い型で作られた値を新しい型として扱う。発見者はここから、メモリの中身を読み書きし、アドレスの乱数化を破り、最後に system() を呼ぶところまでつなげた。

公式は、主な攻撃の道を ALTER … SET DATA TYPE としつつ、ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN のような別の DDL の道もあるとしている。

攻撃の条件は、ログインできることと、オブジェクトを作れることだ。Red Hat は、認証が前提なので認証なしのリモート攻撃にはならないとして、評価を Important（重要）にしている。

ただし、「オブジェクトを作れる」の範囲は思ったより広い。一時オブジェクトを作る TEMPORARY 権限は、データベースを作ったときに PUBLIC（全員）へ与えられる。PostgreSQL 16.15 の手元のクラスタで、スキーマへの CREATE 権限を持たない一般のロールを作って試したところ、CREATE TYPE pg_temp.poc AS (key uuid); は成功した。PostgreSQL 14 以前では、public スキーマへの CREATE 権限も既定で全員にある。アプリ用のアカウントや、分析・読み取り用に配ったアカウントも、攻撃の入り口になりうる。

成功すると、PostgreSQL のサーバーを動かす OS ユーザー（多くは postgres）としてコードが動く。そのデータベースのデータ全体と、サーバー上のファイルに手が届く。

同じ更新で直った52件の内訳

クライアント側のツールの脆弱性は、サーバーのバージョンを上げても直らない。たとえば CVE-2026-116314 は、細工したアーカイブを pg_restore に読ませるとコードが実行される。他人から受け取ったダンプを戻す運用では、運用端末や CI に入っている pg_dump・pg_restore も新しいバージョンにする。

PostgreSQL 14 は 14.25 が最後のリリースで、今後の修正は出ない。13 以前はすでに保守が終わっていて、今回の52件の修正版はない。

CVE-2026-6460 の対策：更新と、作成権限の絞り込み

1. 更新する。 マイナーバージョンの更新なので、ダンプと再読み込みや pg_upgrade は要らず、PostgreSQL を止めてバイナリを入れ替える。ただし、下の3に当てはまる場合や、何回かの更新を飛ばしてきた場合は、入れ替えのあとに追加の作業が要る。サーバーだけでなく、psql・pg_dump・pg_restore などクライアントのパッケージも更新する。マネージドサービスでは自分でバイナリを入れ替えられないので、事業者の告知と更新の予定を確かめる。

2. すぐに更新できないなら、作成権限を絞る。 Red Hat は、PostgreSQL への接続を信頼できる管理用のホストに限り、信頼できないアカウントからオブジェクト作成の権限を外すよう勧めている。ここでいう権限には、スキーマへの CREATE だけでなく、データベースの TEMPORARY も含めて考える。手元の 16.15 では、REVOKE TEMPORARY ON DATABASE postgres FROM PUBLIC; のあと、同じ一般のロールで pg_temp に型を作ろうとすると、permission denied to create temporary tables で止まった。ただし、一時テーブルを使うアプリはこれで動かなくなる。外したあとは、必要なロールにだけ TEMPORARY を与え直す。権限の絞り込みは時間稼ぎで、更新の代わりにはならない。

3. 更新したら、同じリリースで直った不具合の後始末をする。 CVE-2026-6460 とは別に、このリリースは索引やバックアップが壊れる不具合も直している。リリース告知の「Updating」の節は次の作業を挙げている。

何回かの更新を飛ばしてきた場合は、間の版のリリースノートの作業も要る。

自分のシステムを確かめるコマンド

冒頭の版のクエリに加えて、オブジェクトを作れるロールを洗い出す。スーパーユーザーでない、ログインできるロールごとに、一時オブジェクトを作れるか（can_create_temp）と、どこかのスキーマにオブジェクトを作れるか（can_create_in_schema）を返す。

SELECT r.rolname,
  has_database_privilege(r.oid, current_database(), 'TEMPORARY') AS can_create_temp,
  EXISTS (
    SELECT 1 FROM pg_namespace n
    WHERE n.nspname NOT LIKE 'pg\_%' AND n.nspname <> 'information_schema'
      AND has_schema_privilege(r.oid, n.oid, 'CREATE')
  ) AS can_create_in_schema
FROM pg_roles r
WHERE r.rolcanlogin AND NOT r.rolsuper
ORDER BY 1;

PostgreSQL 16.15 の手元のクラスタで、一般のロール（app_user）とスキーマの持ち主（app_owner）を作って試した結果は次のとおりだ。

t が並ぶロールは、更新が終わるまで攻撃の条件を満たす。このクエリは今つないでいるデータベースだけを見るので、データベースごとに実行する。この結果だけでは、攻撃を受けたかどうかは言えない。判定しているのは、条件を満たすロールがあるかという構成だけだ。冒頭の版のクエリも同じで、「修正済み」はこの更新を当てたことを示すだけで、更新の前に侵入されていないことまでは示さない。

コンテナでバージョンを固定している場合は、リポジトリの中も探す。古いバージョンのイメージを指定している箇所が見つかる。

git fetch --all --prune
grep -rnE "(image:|FROM)[[:space:]\"']*[^[:space:]\"']*postgres(ql)?:[0-9]" --include='Dockerfile*' --include='*.yml' --include='*.yaml' .

postgres:16.4 のようなバージョンの指定が見つかったら、修正済みのバージョン（PostgreSQL 16.16 など）以降に上げる。何も見つからなくても、イメージを固定していないだけで、動いているコンテナが修正済みとは限らない。postgres:16 のようにメジャー版だけの指定は、イメージを取り直せば修正版になるが、手元に古いイメージが残っていないかを確かめる。接続文字列の postgres:5432 のような書き方には当たらない。マネージドサービスの版の指定（Terraform の engine_version など）は、このコマンドでは探さないので、別に確かめる。

影響範囲と、まだわかっていないこと

まだわかっていない点は次のとおりだ。

・実際の悪用：公式の発表に、悪用が確認されたという記載はない
・攻撃コードの公開：発見者は 18.6 での実演の動画を公開したが、攻撃コード自体の公開は確かめられていない
・マネージドサービスごとの対応状況：発見者は事業者が独自の緩和策を入れたと書いているが、事業者ごとの完了時期は示していない
・互換製品への影響：PostgreSQL 互換をうたう製品への影響は、発見者の記述にとどまる

発見者は、11月30日のプラハの PostgreSQL ミートアップで、この研究の詳しい話をすると告知している。

ウェブサーバーで同じ週に出た重大な脆弱性は Apache 脆弱性 CVE-2026-119618｜mod_http2のRCEを2.4.71で修正、対象と確認方法 にまとめた。

参照ソース

・CVE-2026-6460: PostgreSQL type confusion after ALTER … SET DATA TYPE executes arbitrary code（PostgreSQL）
・PostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25, and 19 RC 2 Released!（PostgreSQL・2026-11-12）
・Part 3/6 | How I Ended Up Turning a 22-Year-Old PostgreSQL Type-Confusion Primitive into RCE (CVE-2026-6460)（Mehmet Ince・2026-11-09）
・CVE-2026-6460（Red Hat Customer Portal）
・PostgreSQL Versioning Policy（PostgreSQL）