PostgreSQL 15.19 / 17.11 minor release — action may be required for ltree, pgcrypto, btree_gist, and custom operators

[changelog-reporter[bot]]

Postgres minor upgrade to 15.19/17.11 fixes 44 CVEs.
ltree and btree_gist indexes may need reindexing, and pgcrypto data encrypted with legacy ciphers needs re-encryption.

What changed

We are rolling out the PostgreSQL 15.19 / 17.11 minor release (from 15.14 / 17.6).
It bundles five upstream security cycles and closes 44 CVEs.
Four changes may require action, depending on how you use your database:

1. ltree indexes may need reindexing — a case-folding fix on multibyte/ICU databases, plus an integer-overflow fix for very deep ltree values (any encoding).
2. pgcrypto stops decrypting legacy-cipher PGP data (CVE-2026-14663) — data encrypted with cipher-algo=bf/blowfish/cast5 was effectively stored unencrypted and fails to decrypt by default after the upgrade.
3. btree_gist indexes on float columns that may contain NaN need reindexing.
4. Custom operators with non-built-in selectivity estimators (CVE-2026-2004) — recreating them (dump/restore, branching) now requires superuser.

If none of the detection queries below return rows for your project, no action is needed.

Why we made this change

This is an upstream PostgreSQL minor release.
Staying current closes 44 CVEs (including several rated High) and picks up correctness fixes in the ltree and btree_gist extensions.

Who is affected

1. ltree indexes

Case-folding (multibyte/ICU)

After upgrading, indexes on ltree columns built under the previous version can silently return incomplete results on databases using a multibyte encoding (such as UTF-8) or a non-libc collation provider (ICU or builtin).
Check whether your database is affected:

select
  pg_encoding_to_char(encoding) as encoding,
  pg_encoding_max_length(encoding) as max_bytes_per_char, -- 1 = single-byte, >1 = multibyte
  datlocprovider as collation_provider, -- 'c' libc, 'i' icu, 'b' builtin
  (pg_encoding_max_length(encoding) > 1 or datlocprovider != 'c') as reindex_required
from pg_database
where datname = current_database();

If reindex_required is true, find the affected indexes:

select distinct
  n.nspname as schema_name,
  cls.relname as table_name,
  ic.relname as index_name
from pg_index idx
  join pg_class ic on idx.indexrelid = ic.oid
  join pg_class cls on idx.indrelid = cls.oid
  join pg_namespace n on ic.relnamespace = n.oid
  join lateral unnest(idx.indclass::oid[]) with ordinality as k(opclass, pos) on true
  join pg_opclass oc on oc.oid = k.opclass
  join pg_type ty on ty.oid = oc.opcintype
where
  k.pos <= idx.indnkeyatts -- key columns only, excludes INCLUDE
  and ty.typname in ('ltree', '_ltree');

Integer overflow (any encoding)

This release also fixes an integer overflow in ltree comparisons: values with more than about 14,653 labels could compare incorrectly, which can corrupt B-tree indexes built over them, regardless of your database encoding.
This query lists only the B-tree indexes that actually contain such values (an empty result means no action is needed):

select s.schema_name || '.' || s.index_name as index_to_reindex
from (
  select
    n.nspname as schema_name,
    c.relname as table_name,
    ic.relname as index_name,
    min(pg_get_expr(i.indpred, i.indrelid)) as pred, -- partial-index predicate, if any
    string_agg('nlevel(' || pg_get_indexdef(i.indexrelid, k.pos::int, true) || ') > 14653', ' or ') as keys_cond
  from pg_index i
  join pg_class ic on ic.oid = i.indexrelid
  join pg_class c on c.oid = i.indrelid
  join pg_namespace n on n.oid = c.relnamespace
  join pg_am am on am.oid = ic.relam
  join lateral generate_series(1, i.indnkeyatts) as k(pos) on true
  join pg_attribute ia on ia.attrelid = i.indexrelid and ia.attnum = k.pos
  join pg_type t on t.oid = ia.atttypid
  where am.amname = 'btree'
    and t.typname = 'ltree'
    and n.nspname not in ('pg_catalog', 'information_schema')
  group by n.nspname, c.relname, ic.relname
) s
where (xpath(
         '/row/cnt/text()',
         query_to_xml(
           format('select count(*) as cnt from %I.%I where %s(%s)',
                  s.schema_name,
                  s.table_name,
                  case when s.pred is not null then '(' || s.pred || ') and ' else '' end,
                  s.keys_cond),
           false,
           true,
           ''
         )
       ))[1]::text::bigint > 0
order by 1;

2. pgcrypto legacy ciphers (CVE-2026-14663)

If you call pgp_sym_encrypt/pgp_pub_encrypt (or their _bytea variants) with cipher-algo=bf, cipher-algo=blowfish, or cipher-algo=cast5, that data was effectively stored unencrypted — decryption succeeds even with the wrong key.
The default cipher (AES) and 3des are not affected.
If you never passed a cipher-algo option, no action is needed.

To find affected rows, scan each stored value with a deliberately wrong passphrase: properly encrypted values raise an error, while affected values decrypt successfully even with the wrong key.
Run the helper and the scan in the same session (pg_temp functions are session-scoped):

create function pg_temp.affected_by_cve_2026_14663(msg bytea)
returns boolean
language plpgsql as $$
begin
  perform pgp_sym_decrypt_bytea(msg, 'deliberately-wrong-key');
  return true;
exception when others then
  return false;
end $$;

select <id_column>
from <your_table>
where <your_encrypted_column> is not null
  and pg_temp.affected_by_cve_2026_14663(<your_encrypted_column>);

Any rows returned hold affected values.
The scan covers symmetric (pgp_sym_*) messages.
The wrong-key probe does not apply to public-key (pgp_pub_*) messages.
If pgp_pub_encrypt was used with an affected cipher-algo, treat those values as affected and re-encrypt them the same way using pgp_pub_decrypt and pgp_pub_encrypt with the key pair.

3. btree_gist indexes on float columns

Indexes built under the previous version can return wrong results for rows containing NaN until reindexed.
Find btree_gist indexes on float columns:

select distinct
  n.nspname as schema_name,
  cls.relname as table_name,
  ic.relname as index_name
from pg_index idx
  join pg_class ic on idx.indexrelid = ic.oid
  join pg_am am on ic.relam = am.oid
  join pg_class cls on idx.indrelid = cls.oid
  join pg_namespace n on ic.relnamespace = n.oid
  join lateral unnest(idx.indclass::oid[]) with ordinality as k(opclass, pos) on true
  join pg_opclass oc on oc.oid = k.opclass
  join pg_type ty on ty.oid = oc.opcintype
where
  am.amname = 'gist'
  and k.pos <= idx.indnkeyatts
  and ty.typname in ('float4', 'float8');

You are affected only if indexes are returned and those columns may contain NaN values.

4. Custom operators (CVE-2026-2004)

Only superusers may now attach a non-built-in selectivity estimator to an operator.
Existing operators keep working.
Only re-creation (dump/restore, branching, major-version upgrade) fails.

Operators installed by extensions (PostGIS, intarray, etc.) are not affected.
Check for affected operators:

select
  n.nspname as schema, o.oprname as operator,
  o.oprrest::regproc as restrict_estimator,
  o.oprjoin::regproc as join_estimator
from pg_operator o
join pg_namespace n on o.oprnamespace = n.oid
where n.nspname not in ('pg_catalog', 'information_schema')
  and ((o.oprrest <> 0 and o.oprrest::oid >= 10000)
    or (o.oprjoin <> 0 and o.oprjoin::oid >= 10000))
  and not exists (
    select 1 from pg_depend d
    where d.classid = 'pg_operator'::regclass and d.objid = o.oid and d.deptype = 'e'
  );

What happens if you take no action

• ltree / btree_gist: affected index searches may silently return wrong or incomplete results - no error is raised.
• pgcrypto: decryption of affected messages fails by default after the upgrade (recoverable with the ignore-cipher-failure=1 decrypt option).
  The underlying data remains effectively unencrypted at rest until re-encrypted.
• Custom operators: a future dump/restore, branch, or major-version upgrade fails to recreate the operator.

Migration steps

1. Run the detection queries above for each database.
2. After upgrading, reindex each affected ltree/btree_gist index using its schema-qualified name — REINDEX INDEX CONCURRENTLY <schema_name>.<index_name>; runs online with no downtime, but cannot run inside a transaction block.
3. For pgcrypto: re-encrypt affected values with a modern cipher (for example cipher-algo=aes256), before the upgrade or after it using ignore-cipher-failure=1, and consider rotating secrets stored this way.
4. For custom operators: recreate without the RESTRICT/JOIN clause (or with a built-in estimator), or contact support and we'll assist.

Rollout timeline

Date	Milestone	User action
2026-09-25	Release announce (this entry)	Run detection queries
2026-09-28	New projects created on 15.19 / 17.11	—
2026-09-28	Upgrade available in dashboard for existing projects	Upgrade, then reindex if affected

Affected products: Database

Authored by @utkarash2991