本文へ移動
情シスのミカタ
ニュース約7分で読めます

PostgreSQLのJDBCドライバー(pgjdbc)の脆弱性2件、修正版は42.7.14

JavaからPostgreSQLにつなぐJDBCドライバー(pgjdbc)の脆弱性2件(CVSS 5.9と5.3)を、GitHubのアドバイザリとCVE記録で確かめました。対象の版、条件、jarの探し方、委託先やメーカーへの聞き方、Linux各社の状況をまとめます。

公開 情シスのミカタ編集部AIにより執筆チェック済み
文字
PostgreSQLのJDBCドライバー(pgjdbc)の脆弱性2件、修正版は42.7.14

この記事のまとめ

  • pgjdbc(PostgreSQLのJDBCドライバー)の脆弱性2件は、10月7日(UTC)に修正版42.7.14が出ました。CVSS 3.1は5.9と5.3で、深刻度はどちらも「中」です。
  • 5.9の件は、接続設定のrequireAuthに「全部の方式を除外する」値を入れた場合だけです。5.3の件は、アプリが実際のデータより長い「宣言の長さ」を渡す特定の呼び出しを使う場合だけです。
  • 対象は42.7.4〜42.7.13(5.3の件)と42.7.11〜42.7.13(5.9の件)で、それより古い版は、この2件の対象ではありません。悪用の報告は、確かめた資料に記載がありません。
こんな方に#30代#40代#50代実務

JavaのアプリがPostgreSQLにつなぐための部品「pgjdbc」(PostgreSQL JDBCドライバー)に、脆弱性2件が見つかりました。修正版の42.7.14は、2026年10月7日(UTC)に出ています。フランスのANSSI(CERT-FR)が10月12日に注意情報CERTFR-2026-AVI-1292を出しました。

部品の話なので、対象になる会社は限られます。

公式の資料で確かめられたこと

項目 内容 出どころ
修正版 42.7.14(2026年10月7日 21:40 UTC) GitHubのリリース
アドバイザリとCVEの公開 2件とも10月7日(UTC)。CVEの登録元はPostgreSQL GitHub・CVE記録
PostgreSQL公式のお知らせ 10月9日(2件のCVE) postgresql.org
CERT-FRの注意情報 10月12日。対象は「42.7.14より前」と書き、リスクは「機密性の侵害」と「安全対策の回避」 CERT-FR

CERT-FRの書き方は、開発元の範囲より広めです。開発元の範囲は、次の表のとおり件ごとに決まっています。

GitHubのアドバイザリGHSA-rhp9-mr79-r74h。題は requireAuth is silently not enforced when the value excludes every authentication method、深刻度Moderate 5.9、パッケージ org.postgresql:postgresql、影響する版は42.7.11から42.7.13、修正版は42.7.14、CVE-2026-107314
pgjdbcのGitHubアドバイザリ。requireAuthの件(CVSS 5.9)出典: pgjdbc「requireAuth is silently not enforced…」(GitHub)(引用)

2件の内訳

CVE 内容(要約) CVSS 3.1 対象の版
CVE-2026-107314 接続設定requireAuthの値が、ドライバーの知る6方式を全部除外すると、制限がかからない。通信に割り込める攻撃者が、平文のパスワード方式を要求してDBのパスワードを受け取れる 5.9(中) 42.7.11〜42.7.13
CVE-2026-107315 宣言した長さより短い値を送ると、足りない分を0でなく、同じ接続で前に送った通信の中身で埋めて、サーバーが保存する。前の文のSQLや引数が混ざる 5.3(中) 42.7.4〜42.7.13

CVSS 3.1の値は、GitHub、CVE記録、NVDで同じです。

CVE-2026-107314の条件

次の2つが重なる場合だけです。

  • requireAuthに「!password,!md5,!gss,!sspi,!scram-sha-256,!none」のように全方式を除外した値、または「,」のように方式のない値を入れている
  • 通信路に割り込める攻撃者がいる(中間者)

requireAuthは、サーバーに許す認証方式を絞る設定です。初期値はなく、設定していなければ対象外です。「scram-sha-256」のように許す方式を並べた値や、一部だけ除外した値は、正しく働きます。

Nobody sets such a value on purpose, so an affected deployment has it by mistake, and on affected versions its connections work normally, which hides the mistake.

出典: pgjdbc GHSA-rhp9-mr79-r74h

訳すと、意図してそんな値を入れる人はおらず、間違いに気づけない、という意味です。

CVE-2026-107315の条件

アプリが「宣言する長さ」を、実際のデータより長くして渡す場合だけです。正しく作られたアプリ(宣言の長さがデータと同じ)は対象外と、アドバイザリに書かれています。アドバイザリが挙げている入口は次の6つです。

  • PreparedStatement.setObject(int, ByteStreamWriter)
  • CopyIn.writeToCopy(ByteStreamWriter)
  • CopyIn.writeToCopy(byte[], int, int)
  • PGCopyOutputStream.write(byte[], int, int)(64KiB超の書き込み)
  • LargeObject.write(byte[], int, int)
  • java.sql.Blob.setBytes(long, byte[], int, int)

埋まる量は、1つの値につき最大8,192バイトです(GSS暗号化の接続では16,320バイト)。接続プールでは、前の文が別の要求のものだった場合もあります。攻撃者には、そのような値を保存させ、読み出せることが求められます。

止める接続設定はなく、回避策は「宣言の長さをデータに合わせる」ことです。リリースノートには、対象の版で保存した値に、すでに漏れたデータが入っている場合があるので、該当の列を見直すとよい、とあります。

影響する会社・しない会社

  • 影響する: Java製の業務システム(社内開発・委託開発・パッケージ製品)でpgjdbcの42.7.4〜42.7.13を使い、上の6つの入口を使っている会社(107315)
  • 影響する: pgjdbcの42.7.11〜42.7.13を使い、接続設定のrequireAuthに全方式を除外した値(または方式のない値)が入っている会社(107314)
  • 影響する(確認が要る): 製品に同梱されたpgjdbcの版が分からない会社。メーカーに聞きます
  • 影響しない: pgjdbcが42.7.3以前の会社(この2件の対象外)。Java以外でPostgreSQLにつなぐ会社
  • 影響しない: requireAuthを設定していない会社は107314の対象外。上の6つの入口を使っていない、または宣言の長さがいつもデータと同じ会社は107315の対象外

同じ範囲の、これまでの脆弱性

pgjdbcのGitHubには、アドバイザリが11件あります。この2件のほかに、最近の版に関わるものが次の4件あります。更新先の42.7.14は、これらの修正も含みます。

CVE 内容(要約) 深刻度(出どころ) 修正版
CVE-2026-107313 GSS暗号化の接続で、大きな値が前の通信の中身に置き換わる(42.7.4と42.7.5) CVSS 3.1: 4.2(GitHub) 42.7.6
CVE-2026-54291 証明書の方式が未対応だと、チャネルバインディングの認証が黙って弱くなる CVSS 4.0: 8.2(GitHub) 42.7.12
CVE-2026-42198 SCRAM認証のPBKDF2の繰り返し回数に上限がなく、CPUを使い切られる(42.2.0〜42.7.10) CVSS 3.1: 7.5(GitHub) 42.7.11
CVE-2025-49146 channelBinding=require でも安全でない認証に切り替わる CVSS 3.1: 8.2(GitHub) 42.7.7

Linux各社の状況

編集部が10月13日に開けたページで確かめたものです。

  • Debian(パッケージ名libpgjava): 107314は、bookworm(42.5.5)とtrixie(42.7.7)が「対象外」、forky(42.7.13-1)が脆弱、sid(42.7.14-1)が修正済みです。107315は、bookworm・trixie・forkyが「vulnerable」、sidが修正済みです。bookwormの42.5.5は、開発元の範囲(42.7.4以降)の外ですが、トラッカーは「vulnerable」と書いています。理由は確かめられませんでした
  • Red Hat: 2件とも、深刻度は「Moderate」です。RHEL 9と10のpostgresql-jdbcは「Not affected」です。Red Hat製品のAMQ Broker 7、Debezium 3、Keycloakなどは「Fix deferred」(修正は延期)でした。更新(RHSA)の記載は確かめられませんでした

情シスが今日やること

  1. pgjdbcの版を探す。サーバーで find / -name "postgresql-*.jar" 2>/dev/null を実行します。Mavenなら mvn dependency:tree、Gradleなら gradle dependencies で、org.postgresql:postgresqlの版を見ます。WARやfat jarの中は unzip -l で見ます(編集部の補足)
  2. 版が42.7.4〜42.7.13なら、開発元に更新を頼む。社内開発なら開発担当、委託開発なら委託先、パッケージ製品ならメーカーです。「pgjdbcを42.7.14以降へ上げた版を、いつ提供できるか」を聞きます
  3. 接続設定にrequireAuthがないかを探す。JDBC URL、設定ファイル、アプリサーバーのデータソース設定(例: grep -r requireAuth 設定のフォルダ)です。値が全方式の除外なら、許す方式を並べた値に直します。更新後は、この値のままだと接続できません
  4. 開発元に、上の6つの入口の使用を聞く。「宣言の長さがデータより長くなる箇所があるか」「保存済みの列に、混ざったデータがないか」です。使っていなければ、107315は条件に当たりません
  5. すぐ更新できない場合は、DBへの通信にTLSを使い、サーバー証明書を確かめる設定(sslmode=verify-full)にする。107314の公式の回避策に、この記載があります。

書かれていないこと

次の点は、確かめた資料に書かれていません。この記事でも書きません。

  • 悪用された事例。アドバイザリにも、CERT-FRの注意情報にも記載がありません。「悪用されていない」という意味ではありません。CISAのSSVC(優先度の判定)は、107314が「Exploitation: none」、107315が「poc」(再現の手順が公開されている)でした
  • 42.7.4より前の系統(42.2系など)で、107315と同じ動きがないか。開発元の記載は「42.7.3以前は0で埋める」です
  • Debianのbookwormが107315で「vulnerable」になっている理由、Linux各社が各件を直す版と日付

よくある質問

Qpgjdbcの版を上げないと、PostgreSQLのデータが外から抜かれますか?

A資料には、そうは書かれていません。5.9の件は、設定ミスと、通信に割り込める攻撃者の両方が要ります。5.3の件は、アプリが長さを間違えて渡す呼び出しがあり、その値を保存して読み出せる利用者がいる場合です。どちらも悪用の報告は記載がありません(10月13日時点)。

Qうちのjarは postgresql-42.2.x.jar です。この2件の対象ですか?

Aこの2件の対象ではありません。対象は42.7.4以降(5.3の件)と42.7.11以降(5.9の件)です。ただし42.7.11より古い版には、4月以降に公表された別の脆弱性があります。この記事の表を見てください。

QANSSI(CERT-FR)は「42.7.14より前」と書いています。全部が対象ですか?

ACERT-FRの書き方は広めです。開発元のアドバイザリでは、対象の範囲は件ごとに決まっています。自社の版が範囲に入るかは、開発元の範囲で確かめます。

Qパッケージ製品の中のpgjdbcは、どう確かめますか?

Aメーカーに、同梱のpgjdbcの版と、42.7.14以降を入れた版の提供時期を聞きます。jarを自分で差し替えると、サポートの対象外になることがあります。

出典・参考

チェック済み。この記事は監修者によってチェックされました。(2026年10月13日)

執筆

情シスのミカタ編集部AIにより執筆

書いた AI: AI記者(解説)

法令・官公庁の発表・企業の公式発表などの一次情報を調べて、情シス向けの解説・比較・テンプレの記事を書きます。数字と日付は出典と照らして確かめ、記事の最後に出典を載せています。使っているAI: Anthropic Claude。

監修

佐々木 航株式会社Game

代表取締役。工学部出身で、21歳で起業してからシステム会社の経営一筋で8期目。アプリの受託開発から始め、いまはAIを使ったシステムソリューションを手がけています。150社以上の企業とのプロジェクトで培った開発と情報システムの現場の経験と声を形にし、激動の時代を乗り越えたいと考えています。

メモ: 掲載時に自動で(しばらくの間)

記事は AI が一次情報を調べて書き、機械の検査を通してから公開しています。人が見ているもの・見ていないものはAI の使い方に書いています。まちがいに気づいたら訂正・ご指摘からお知らせください。直したら、記事の最後に何を直したかを書きます。

役に立ったら、いいねと共有をお願いします