PostgreSQLの脆弱性CVE-2024-10979とは？PL/Perlで任意コード実行に至る仕組みと影響バージョン・確認手順【2026年10月時点】

CVE-2024-10979は、PostgreSQLの手続き言語PL/Perlが持つ環境変数の制御不備です。データベースの一般ユーザー権限しか持たない相手が、サーバプロセスのPATHなどを書き換えられ、そこから任意のコード実行につながります。修正版は17.1・16.5・15.9・14.14・13.17・12.21の6系統で、いずれも2024年11月14日に公開されました。この記事では、CVSS 8.8が前提にしている権限、自分の環境が影響下にあるかを全データベース分確かめる手順、そして2026年10月2日時点でこのCVEだけを見ていると何を取りこぼすのかを、PostgreSQL公式のアドバイザリに沿って整理します。

まとめ：CVE-2024-10979の影響有無と2026年10月時点の推奨マイナー版

やることは1つです。マイナーバージョンを確認し、修正版ではなく各系統の現行マイナーまで上げてください。17.1で止めた環境には、17系だけで46件のCVE修正が未適用で残っています。すぐ再起動できない場合は、PL/PerlのUSAGE権限をPUBLICから外して新規関数の作成を止め、次の定例である2026年11月12日までに更新を済ませます。

CVE-2024-10979の影響バージョン・修正版とCVSS 8.8が前提とする権限

公式アドバイザリの説明は、PL/Perlにおける環境変数の制御が不適切なため、権限を持たないデータベースユーザーがPATHのようなプロセス環境変数を変更でき、それはDBサーバのOSユーザーを持っていない攻撃者にも任意コード実行を許すのに十分なことが多い、という趣旨です。報告者はCoby Abrams氏です。

影響バージョンと修正版6系統の対応表と2026年10月時点の各系統の状態

影響を受けるのは、下表の修正版より前のすべてのマイナーバージョンです。右列は公式のバージョニングポリシーに載る2026年10月2日時点の状態です。

18系はCVE-2024-10979の影響を受けません。18.0（2025年9月25日）の時点で修正が入っているためです。一方で12系が対象に含まれる点は見落とされがちです。12.21の1週間後、2024年11月21日の12.22が12系の最終版になりました。

CVSS 8.8のベクトルPR:Lが示す認証済み一般ユーザーという前提条件

ベクトルはAV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hです。公式ページの見出しはCVSS 3.0ですが、NVDではNVD自身の評価とPostgreSQL（CNA）の評価がいずれもCVSS 3.1の8.8で、ベクトルも一致します。CWEはPostgreSQL側がCWE-15、NVD側がCWE-610です。CVSSの各項目の読み方は脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説で整理しています。

注意したいのはPR:Lです。攻撃の起点は認証を通過したDBユーザーで、未認証のリモート攻撃ではありません。アプリ用ロールの認証情報が漏れた場合や、複数テナントで同じインスタンスを共有する構成では、この条件が現実に成立します。悪用状況は、CISAのKEVカタログ（2026年10月1日版）に掲載がなく、NVDに付いたCISAのSSVC評価（2024年11月20日）もexploitation: noneです。

trusted PL/Perlの%ENV書き換えから任意コード実行に至る仕組みと修正内容

trusted plperlとuntrusted plperluの権限境界が破れた構図

PostgreSQLは手続き言語をtrustedとuntrustedに分けます。trusted言語は通常のSQL実行環境の外へのアクセスを与えないとみなされ、一般ユーザーにも開放できます。PL/Perlはtrusted側で、ファイル操作のような処理はPerlのOpcodeモジュールで遮断する前提です。フルのPerlが使えるplperluで関数を作れるのはスーパーユーザーだけです。

CVE-2024-10979は、一般ユーザーに開放してよいとされていたtrusted側から環境変数を書き換えられた、という欠陥です。だからPR:Lで成立します。

17.1で入った%ENVのtied hash化と警告つき拒否で変わる既存関数の挙動

17.1のリリースノートは、trustedなPLは環境変数を操作する能力を提供してはならないとし、%ENVを変更の試みを警告とともに拒否するtied hashに置き換えたと記載しています。plperluは従来どおり環境を変更できます。

拒否はエラーではなく警告です。手元のPostgreSQL 17.11（Dockerの公式イメージpostgres:17-alpine）で、$ENV{PATH}へ代入するplperl関数を実行するとWARNING: attempted alteration of $ENV{PATH}が出て、関数自体は最後まで実行されました。環境変数の書き換えに依存した既存関数は、更新後もエラーにならず、その処理だけが効かなくなります。ログのWARNINGを拾える監視を先に用意しておくと、影響の洗い出しが楽になります。

自環境が影響を受けるかを全データベース分確かめる確認SQLとシェル手順

確認するのはマイナーバージョンと、plperlがどのデータベースに入っているかの2点です。版の確認方法そのものはPostgreSQLのバージョン確認方法｜サーバ・クライアント別コマンドとEOL判定・更新計画で詳しく扱っているので、ここではCVEの判定に必要な形に絞ります。

稼働中サーバのマイナーバージョンを推奨版と比べる更新判定SQL

パッケージの表示ではなく、サーバ側のserver_version_num（17.11なら170011）で判定します。下のSQLは2026年10月2日時点の現行マイナーと比べ、is_latest_minorがfなら更新対象です。13系以前はNULLになり、その時点でサポート外と判断できます。

SELECT current_setting('server_version') AS running,
       CASE current_setting('server_version_num')::int / 10000
         WHEN 18 THEN 180006 WHEN 17 THEN 170011 WHEN 16 THEN 160015
         WHEN 15 THEN 150019 WHEN 14 THEN 140024 END AS latest_num,
       current_setting('server_version_num')::int >=
       CASE current_setting('server_version_num')::int / 10000
         WHEN 18 THEN 180006 WHEN 17 THEN 170011 WHEN 16 THEN 160015
         WHEN 15 THEN 150019 WHEN 14 THEN 140024 END AS is_latest_minor;

比較値は四半期ごとに古くなります。2026年11月12日の定例以降は、バージョニングポリシーの表で現行マイナーを確かめて数字を差し替えてください。

plperlの導入有無を全データベースで巡回して確認するシェルループ

拡張の導入状況を示すpg_extensionはデータベースごとのカタログです。postgresデータベースに接続して0行でも、アプリ用の別データベースにplperlが入っていれば影響を受けます。手元の17.11環境でも、postgresでは0行、appdbでは1行という結果になりました。接続できる全データベースを巡回します。

for db in $(psql -U postgres -Atc "SELECT datname FROM pg_database WHERE datallowconn"); do
  psql -U postgres -d "$db" -Atc \
    "SELECT current_database(), extname, extversion FROM pg_extension WHERE extname LIKE 'plperl%'"
done

何も出力されなければ、どのデータベースにもplperl・plperluは入っていません。データベース名に空白を含む環境ではこのループが名前を分割するので、psqlの\lで一覧を見て個別に確認してください。pg_available_extensionsのinstalled_versionがNULLなら、パッケージは配置済みでも有効化されていない状態です。

plperlの利用権限と既存PL/Perl関数を棚卸しするSQLと実行時の注意

plperlが見つかったデータベースでだけ、次のSQLを実行します。未導入のデータベースでhas_language_privilegeを呼ぶと、falseではなくERROR: language "plperl" does not existで止まります。

-- trusted かどうかと ACL（NULL は既定＝PUBLIC に USAGE あり）
SELECT lanname, lanpltrusted, lanacl FROM pg_language WHERE lanname LIKE 'plperl%';

-- 特定ロールが plperl で関数を作れるか
SELECT has_language_privilege('app_user', 'plperl', 'USAGE');

-- 作成済みの PL/Perl 関数を洗い出す
SELECT n.nspname AS schema, p.proname AS function, l.lanname AS language
FROM pg_proc p
JOIN pg_language l ON l.oid = p.prolang
JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE l.lanname IN ('plperl', 'plperlu')
ORDER BY 1, 2;

3つ目の結果は2度使います。更新後に挙動が変わる関数の洗い出しと、緩和策を選ぶときの前提確認です。ロール設計そのものを見直すならPostgreSQLのロールと権限設計｜CREATE ROLEの属性とGRANT・既定権限の決め方が参考になります。

修正版へのマイナーアップデート手順と再起動できない場合のUSAGE剥奪

PGDGパッケージでplperlとクライアントまで揃えて上げる更新コマンド

バージョニングポリシーは、マイナーアップグレードにダンプとリストアは不要で、サーバを止めてバイナリを入れ替え、再起動するだけでよいとしています。ただし追加手順が要る場合があるので、先にリリースノートを読むよう求めています。

見落としやすいのはパッケージの分かれ方です。PostgreSQL公式リポジトリ（PGDG）ではplperlが別パッケージで、Debian系はpostgresql-plperl-17、RHEL系はpostgresql17-plperlです。どちらも17.11が配布されています。8月の定例ではpg_dumpやpsqlなどクライアント側にも8.8のCVEがあるため、サーバだけでなく関連パッケージを揃えて上げます。他のDB製品の脆弱性対応と比べる例として、MongoDBのMongoBleed（CVE-2025-14847）も参考になります。

# Debian / Ubuntu 系（PGDG・PostgreSQL 17 の例）
sudo apt-get update
sudo apt-get install --only-upgrade postgresql-17 postgresql-client-17 postgresql-plperl-17
sudo systemctl restart postgresql

# RHEL 系（PGDG・PostgreSQL 17 の例）
sudo dnf update 'postgresql17*'
sudo systemctl restart postgresql-17

# 反映確認（再起動後のサーバの実行バージョン）
psql -U postgres -Atc "SHOW server_version_num;"

停止時間が問題になる構成では、レプリカを先に更新してからスイッチオーバーする順で影響を抑えられます。手順はrepmgrとは？PostgreSQLのレプリケーション管理と自動フェイルオーバー構築を解説【2026年版】で扱っています。マネージドサービスでは、提供されているマイナー版を各サービスの公式で確認してください。

再起動を待てない場合のREVOKE USAGEで止まる範囲と止まらない範囲

PL/Perlの公式ドキュメントは、trusted PL/PerlがOpcodeモジュールに依存している点に警告を置き、その不確実性がセキュリティ要件と両立しないならREVOKE USAGE ON LANGUAGE plperl FROM PUBLICを検討するよう案内しています。

-- plperl が入っている各データベースで実行する
REVOKE USAGE ON LANGUAGE plperl FROM PUBLIC;
GRANT USAGE ON LANGUAGE plperl TO batch_role;

-- 剥奪後の確認（app_user は f、lanacl から PUBLIC の U が消える）
SELECT has_language_privilege('app_user', 'plperl', 'USAGE');
SELECT lanname, lanacl FROM pg_language WHERE lanname = 'plperl';

17.11の検証環境では、剥奪後にapp_userの判定がf、lanaclが{postgres=U/postgres}になりました。この権限剥奪で止められる操作は限定的です。権限の公式定義では、手続き言語のUSAGEは関数を作るための権限で、呼び出しはEXECUTEで制御されます。止まるのは新規のPL/Perl関数とDOブロックの作成で、既存関数は呼び出せます。後述のCVE-2026-14670は関数の所有者が細工した関数本体で成立するため、既存関数の所有者も棚卸しの対象です。

plperlを業務で使っていないなら、関数がゼロであることを確かめてDROP EXTENSION plperlで外すほうが運用は単純です。どちらも暫定策で、修正版への更新の代わりにはなりません。

2026年10月時点で17.1や17.10のまま止めてはいけない理由と更新判断

CVE-2024-10979のために17.1へ上げ、そのまま運用している環境は対応済みではありません。2026年5月の17.10で止めた環境も同じです。

2026年8月13日の定例で17系に入った25件とPL/Perlの後続CVE

公式のセキュリティ一覧を17系で数えると、17.1より後の修正は46件です。内訳を見ると、2025年に7件、2026年に39件（17.8で4件、17.10で10件、17.11で25件）の修正が行われています。17.11の25件のうち10件は、CVE-2024-10979と同じCVSS 8.8・PR:Lで、任意コード実行に至りうるものです。

主題と直結するのはCVE-2026-14670です。plperlの関数がtied hashを返す処理にヒープバッファオーバーフローがあり、関数の所有者が細工した関数本体で、DBを動かすOSユーザーの権限で任意コードを実行できます。CVE-2024-10979の修正で%ENVがtied hashになったのとは別の箇所の欠陥ですが、どちらもPL/Perlで関数を作れるユーザーが起点になる点は共通です。CVE-2026-14677は32bitビルドに限られます。

修正が後続リリースで直された17.2・17.9・18.5未リリースの3事例

CVEを1件つぶせば終わり、という運用が成り立たない理由はPostgreSQL自身の履歴にあります。

• 17.2（2024-11-21）：17.1がtimescaledbなどの拡張とのバイナリ互換性を壊した点と、CVE-2024-10978の修正がロール設定を適用しなくなった不具合を是正
• 17.9（2026-02-26）：17.8のCVE-2026-2006修正が過剰で、正しい文字列でもエラーになる点を是正
• 18.6（2026-08-13）：18.5はwrap後に回帰が見つかったため公開されず、18.4から18.6へ進んだ

CVE-2024-10979に対応して17.1を当てた環境は、その時点で17.2まで進む必要がありました。修正版の番号を覚えるより、現行マイナーへ上げ続ける運用のほうが漏れません。

17.11へ上げる前に確認する出力プラグイン制限とpgcrypto復号の変化

17.11のリリースノートは、冒頭3件のセキュリティ項目に更新後の設定変更やデータ整理が要りうると書いています。業務システムで影響が出やすいのは次の2つです。

1つ目は論理デコーディングです。CVE-2026-6471の修正でoutput_plugin_librariesが新設され、既定はpgoutput, test_decodingだけです（17.11の検証環境でSHOW output_plugin_libraries;の結果も同じでした）。wal2jsonなど外部の出力プラグインでCDCを組んでいる環境は、更新後にこの設定へ追加しないと止まります。SELECT slot_name, plugin FROM pg_replication_slots;で使用中のプラグインを先に確認してください。

2つ目はpgcryptoです。CVE-2026-14663は、OpenSSLが拒否した暗号（FIPSモードでのblowfishやcast5など）でPGP暗号化すると容易に解読できる状態で保存されていた問題で、修正後は該当データの復号が既定で失敗します。列暗号化の設計はPostgreSQLの暗号化｜TLS設定・pgcryptoの列暗号化とTDE不在時の選び方を参照してください。

13・12のEOLと2026年11月12日に終わる14系の移行判断

PostgreSQLはメジャーバージョンを初回リリースから5年間サポートします。13系は2025年11月13日の13.23、12系は2024年11月21日の12.22で終わり、2026年のCVEに対する修正マイナーは出ていません。13.17や12.21でCVE-2024-10979だけ直した環境には、以降の欠陥が積み上がったまま残ります。サーバ本体とは別に、管理ツールのpgAdminにも2026年10月29日公開の9.19で直った脆弱性が15件あります。対応手順はpgAdminの脆弱性：9.19で直った15件のCVEと更新前に要るサーバーモードの設定にまとめています。

14系は2026年11月12日の定例が最後のリリースで、残りは約6週間です。14系で動かしているシステムは、マイナー更新ではなくメジャーアップグレードの計画に入る段階です。次のメジャー版PostgreSQL 19はロードマップで2026年10月予定とされ、9月24日にBeta 4が出ています。業務システムの移行先は、拡張の対応状況が揃っている18系を基本にし、19系は最初の数マイナーを見てから判断するのが堅実です。移行の設計や切替の手順まで外部に任せたい場合は、データベース設計・移行支援で相談を受けています。

年4回の定例マイナーリリースに追随する運用と見送ってよい場面

定例は原則として2月・5月・8月・11月の第2木曜日で、公表済みの日程は2026年11月12日、2027年2月11日、5月13日、8月12日です。重大な問題があれば定例の間にもリリースされるため、公開回数はこの一覧だけに限りません。予定日をカレンダーに固定し、リリースノートを読んで数日以内に検証環境へ当てる周期を作るのが現実的です。導入済みパッケージの脆弱性を継続的に拾う仕組みはOSV-Scannerとは？Google製OSS脆弱性スキャナの使い方とTrivyとの違いが参考になります。

即日適用を見送ってよいのは、plperlがどのデータベースにも無く、DBユーザーがアプリ用の単一ロールに限られ、外部の出力プラグインやpgcryptoのPGP暗号を使っていない環境です。この場合でも次の定例までに上げます。逆に、複数の利用者に一般ロールを配っている共有インスタンスは見送れません。

よくある質問

CVE-2024-10979とPostgreSQLの更新判断で、よく確認される点をまとめます。

PostgreSQL 18はCVE-2024-10979の影響を受けますか？

受けません。公式アドバイザリの影響範囲は17・16・15・14・13・12の各系統で、18系は18.0の時点で修正を含んでいます。ただし18系にも2026年8月13日の18.6で修正されたCVEが28件あり、CVE-2026-14670のようにPL/Perlに関わるものも含まれます。18系なら18.6以降へ上げてください。

自分のPostgreSQLのバージョンはどう確認しますか？

接続してSHOW server_version_num;またはSELECT version();を実行します。17.11なら170011と返ります。パッケージの表示やpsqlのクライアント版は、更新後に再起動していない環境では実際に動くサーバの版と一致しません。判定は必ずサーバ側の値で行ってください。

マイナーバージョンアップにダンプとリストアは必要ですか？

不要です。公式のバージョニングポリシーは、サーバを止めてバイナリを入れ替え、再起動するだけでよいとしています。ただし17.11のように更新後の設定追加が要る回もあるため、先にリリースノートを読むよう案内されています。ダンプとリロードまたはpg_upgradeが要るのはメジャーバージョンの移行です。

CVSS 8.8ということは、未認証でもインターネットから攻撃されますか？

されません。PR:Lは低い権限が必要という意味で、起点は認証を通過したDBユーザーです。アプリ用ロールの認証情報が漏れた場合や、複数の利用者に同じインスタンスを開放している構成では条件が成立します。攻撃面はネットワークよりDBアカウントの管理にあると読み替えて、優先度を決めてください。

2026年10月時点のPostgreSQLの最新バージョンはどれですか？

メジャー版は18で、現行マイナーは18.6です。サポート中の各系統は18.6・17.11・16.15・15.19・14.24で、いずれも2026年8月13日の公開です。次の定例は2026年11月12日で、14系はこの回で終わります。PostgreSQL 19は2026年10月の公開予定です。

関連記事

• PostgreSQLのバージョン確認方法｜サーバ・クライアント別コマンドとEOL判定・更新計画：版確認とEOL判定の詳細
• PostgreSQLのロールと権限設計｜CREATE ROLEの属性とGRANT・既定権限の決め方：PR:Lの脆弱性に備えるロール設計
• 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説：CVSSベクトルの読み方
• SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説：依存ソフトの脆弱性を継続管理する方法
• repmgrとは？PostgreSQLのレプリケーション管理と自動フェイルオーバー構築を解説【2026年版】：停止時間を抑えた更新の前提になる構成