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の書き方は、開発元の範囲より広めです。開発元の範囲は、次の表のとおり件ごとに決まっています。
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
訳すと、意図してそんな値を入れる人はおらず、間違いに気づけない、という意味です。
修正版では、全方式を除外した値のまま接続すると、接続が失敗します(SQLState 08004)。更新の前に、許す方式を並べた値(例: requireAuth=scram-sha-256)へ直します。
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)の記載は確かめられませんでした
情シスが今日やること
pgjdbcの版を探す。サーバーで find / -name "postgresql-*.jar" 2>/dev/null を実行します。Mavenなら mvn dependency:tree、Gradleなら gradle dependencies で、org.postgresql:postgresqlの版を見ます。WARやfat jarの中は unzip -l で見ます(編集部の補足)
版が42.7.4〜42.7.13なら、開発元に更新を頼む。社内開発なら開発担当、委託開発なら委託先、パッケージ製品ならメーカーです。「pgjdbcを42.7.14以降へ上げた版を、いつ提供できるか」を聞きます
接続設定にrequireAuthがないかを探す。JDBC URL、設定ファイル、アプリサーバーのデータソース設定(例: grep -r requireAuth 設定のフォルダ)です。値が全方式の除外なら、許す方式を並べた値に直します。更新後は、この値のままだと接続できません
開発元に、上の6つの入口の使用を聞く。「宣言の長さがデータより長くなる箇所があるか」「保存済みの列に、混ざったデータがないか」です。使っていなければ、107315は条件に当たりません
すぐ更新できない場合は、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各社が各件を直す版と日付