まず、バージョン番号の読み方とサポートの決まりです。ここを知っておくと、見積書や運用の会話が通じるようになります。

出典：PostgreSQL『Versioning Policy』（2026年8月22日に確認）。「最低でも3か月に1回」という頻度は、脆弱性が定期的に見つかることを前提にした設計です。止めたまま何年も動かす使い方は、そもそも想定されていません。

そして、いま動いているバージョンがいつまで使えるのかは、表になって公開されています。

出典：同上。最新のマイナー版は2026年8月13日にリリースされた 18.6／17.11／16.15／15.19／14.24 です。この記事の作成時点で、14のサポート終了まで3か月を切っています。13はすでに2025年11月に終わっています。

第1章 おわり — 次は第2章

PostgreSQLプロジェクトは、脆弱性の情報を1ページにまとめて公開しています。そこには、どのメジャー版に存在するか、どのマイナー版で直ったか、悪用に有効なログインが必要か、CVSSのスコアはいくつか、まで載っています。実際に数えると、こうなりました。

出典：PostgreSQL『Security Information』の一覧を2026年8月22日に取得し、筆者が集計した実数です。この一覧は「サポート中のバージョン」で絞られた表示なので、過去に修正済みでサポート終了版にしか残っていないものは含まれていません。CVSSの読み方はCVSSの記事で扱っています。

件数より大事なのが、次の内訳です。攻撃するのに、どれだけの権限が要るかで分けました。

同じ一覧のCVSSベクタ（PR＝Privileges Required）を集計しました。70件のうち50件は、攻撃者が何らかのアカウントでログインできることが前提です。裏を返せば、残る20件はネットワークから到達できるだけで条件が揃います。だから「外に出さない」と「権限を絞る」は、どちらか片方では足りません。

もうひとつ、この一覧の性格を知っておくと役に立ちます。PostgreSQLプロジェクトはCVE番号を自分で採番できる機関（CNA）で、Red Hatをルートとして運用されています。脆弱性を見つけて報告すると、プロジェクト側でCVEを登録し、リリースノートに報告者を記載する仕組みです。

第2章 おわり — 次は第3章

個人情報保護委員会は令和7年度の年次報告で、不正アクセスによる漏えいの原因として、脆弱性の放置、推測されやすいID・パスワード、そして設定ミスによりデータベースへのアクセス制御が不適切な状態になっていたことを挙げています。PostgreSQLに引き直すと、入口は4つに分かれます。

上の3つは設定の話で、いちばん下だけが製品の更新の話です。この辞典のデータベースの記事で扱った5段階のうち、1段目と2段目に相当します。ここで止められれば、その先には進まれません。

2つ目の「認証が緩い」について、公式ドキュメントがはっきり書いています。trustという認証方式の説明です。

同じ節には、使ってよい場面の限界も書かれています。

つまりtrustは、1人で使う作業用パソコンでは便利で適切、それ以外ではほぼ不適切という位置づけです。検証環境で設定して、そのまま本番に持っていく形が事故になります。

3つ目の「権限が広すぎる」については、もっと踏み込んだ前提があります。PostgreSQLのセキュリティチームは、脆弱性として扱う範囲をこう定めています。

出典：PostgreSQL『Security Information』「What is a Security Vulnerability in PostgreSQL?」。なお同プロジェクトは報奨金制度（バグバウンティ）を設けていないと明記しています。

第3章 おわり — 次は第4章

まず、まわりの名前を整理します。どれも「データベースを預かるソフト」ですが、想定している使い方が違います。

SQLiteは端末の中に置かれることが多く、デジタルフォレンジックではアプリの利用痕跡を残すファイルとしてよく登場します。同じ「データベース」でも、守り方も調べ方も変わります。

誤解も並べておきます。

1つ目について補足します。この記事が数字を書けているのは、PostgreSQLが件数もCVSSも必要な権限も公開しているからです。公開していない製品について同じ表は作れません。比べられないことと、安全であることは違います。

第4章 おわり — 次は第5章

個人でPostgreSQLを触るのは、たいてい学習か個人開発です。事故が起きるのは、練習のつもりで作った環境をそのまま外に置いたときです。やることは3つだけです。

3つ目は個人だけの話ではありません。企業でも、テスト環境に本番のデータを置いていた、という形の漏えいは繰り返し起きています。脆弱性診断の点検項目にも同じ項目があります。

第5章 おわり — 次は第6章

細かい設定項目は数えきれないほどありますが、被害の大きさを決めるものは限られています。上の3つができていれば、第3章の入口のうち3つが閉まります。

3番目は、この記事でいちばん強調したい項目です。PostgreSQLはスーパーユーザーの操作を脆弱性として扱いません。それは裏返せば、スーパーユーザーの権限を渡した時点で、製品側の防御はもう期待できないということです。7番目はログ管理の話につながります。

4番目の運用は、あらかじめ性質を知っておくと計画が立てやすくなります。

出典：PostgreSQL『Versioning Policy』および『Security Information』。「常に入手可能な最新のマイナー版を使うことを推奨する」と公式が明記しています。メジャー更新の議論が止まっていても、マイナーだけは進められます。

第6章 おわり — 次は第7章

新しい脆弱性が公表された、あるいは使っている版のサポート終了が近い。どちらの場合も、まず自社に当てはまるかどうかを確かめます。全部を調べる前に、条件で絞ります。

3行目が実務では効きます。同じCVSSでも、権限不要のものが外向きのサーバにあれば最優先、ログインが要るものが社内限定のサーバにあれば順位は下がります。公式の一覧には、この判断に必要な情報が最初から載っています。

サポート終了が近い場合は、判断がもう少し単純です。期限は動きません。動かせるのは着手日だけなので、検証にかかる期間を見積もって逆算します。移行の作業自体は、公式が用意している手順に沿って行います。

第7章 おわり — 次は第8章

この用語とセットで覚えると理解が早くなる語です。

第8章 おわり — 最後にFAQ