Skip to content

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

Sep 25, 2026

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:


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

If reindex_required is true, find the affected indexes:


_14
select distinct
_14
n.nspname as schema_name,
_14
cls.relname as table_name,
_14
ic.relname as index_name
_14
from pg_index idx
_14
join pg_class ic on idx.indexrelid = ic.oid
_14
join pg_class cls on idx.indrelid = cls.oid
_14
join pg_namespace n on ic.relnamespace = n.oid
_14
join lateral unnest(idx.indclass::oid[]) with ordinality as k(opclass, pos) on true
_14
join pg_opclass oc on oc.oid = k.opclass
_14
join pg_type ty on ty.oid = oc.opcintype
_14
where
_14
k.pos <= idx.indnkeyatts -- key columns only, excludes INCLUDE
_14
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):


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


_14
create function pg_temp.affected_by_cve_2026_14663(msg bytea)
_14
returns boolean
_14
language plpgsql as $$
_14
begin
_14
perform pgp_sym_decrypt_bytea(msg, 'deliberately-wrong-key');
_14
return true;
_14
exception when others then
_14
return false;
_14
end $$;
_14
_14
select <id_column>
_14
from <your_table>
_14
where <your_encrypted_column> is not null
_14
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:


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


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

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#

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

Build in a weekend, scale to millions

Start your projectRequest a demo