Supabase Patches 44 Postgres CVEs, Some Fixes Need Your Action

Supabase starts defaulting new projects to Postgres 15.19 and 17.11 today, a minor-version bump that bundles five upstream security cycles and closes 44 CVEs. Four of the underlying fixes are breaking changes serious enough to need manual follow-up, not just a restart (Supabase changelog, Sept. 25, 2026).

The upgrade moves projects from 15.14/17.6 to 15.19/17.11. Existing projects can upgrade through the dashboard on their own schedule; new projects get the patched versions automatically starting Sept. 28.

---

Four fixes that aren’t silent

Most point-release CVE patches roll through unnoticed. Supabase called out four here as breaking:

• ltree indexes: a case-folding bug in multibyte and ICU-collation databases, plus an integer-overflow fix for ltree values nested more than 14,653 labels deep, can leave existing B-tree indexes corrupted. They keep running, but may return incomplete results until rebuilt.
• pgcrypto’s legacy ciphers (CVE-2026-14663): data encrypted with cipher-algo=bf, blowfish or cast5 was, in Supabase’s own description, “effectively stored unencrypted.” Decrypting that data now fails by default after the upgrade instead of silently succeeding against a broken cipher.
• btree_gist on float columns: indexes holding NaN values, built under the old version, can return incorrect results until reindexed.
• Custom selectivity estimators (CVE-2026-2004): attaching a non-built-in selectivity estimator to a custom operator now requires superuser privileges. Existing operators keep working; recreating one without superuser access fails.

None of the four breaks automatically. Supabase is shipping detection queries to flag which objects in a given project are actually affected, and every fix runs online: REINDEX INDEX CONCURRENTLY for the index issues, a re-encryption pass for pgcrypto data still on the deprecated ciphers.

What to do about it

Run Supabase’s detection queries before the Sept. 28 default flip reaches an existing project, not after. Reindex any flagged ltree or btree_gist index with REINDEX INDEX CONCURRENTLY, which runs online without blocking writes. Re-encrypt any pgcrypto data still using bf, blowfish or cast5 with a current cipher before relying on decrypting it post-upgrade. Recreate any custom operator with a non-built-in selectivity estimator only from a superuser role, since the operator itself keeps working but recreation without one will fail.

---

Key Takeaways

• Postgres 15.19/17.11 closes 44 CVEs across five upstream security cycles; new Supabase projects default to it starting Sept. 28, 2026.
• pgcrypto data encrypted with cipher-algo=bf, blowfish or cast5 (CVE-2026-14663) was effectively unencrypted; decryption fails by default post-upgrade unless re-encrypted first.
• ltree and btree_gist indexes may need REINDEX INDEX CONCURRENTLY to avoid returning incomplete or incorrect results.
• Custom selectivity estimators (CVE-2026-2004) now require superuser privileges to attach. Existing operators still work, but recreating one doesn’t without that role.
• Supabase is shipping detection queries so teams can check which of the four breaking changes actually apply to their project before upgrading.

---

The take

Bundling five security cycles into one release note, then walking customers through exactly which pieces need a manual follow-up, is a more useful disclosure than a changelog line that just says “upgrade now.” Triage the pgcrypto cipher flaw first. Data that was “effectively stored unencrypted” is a confidentiality problem the moment it was written, not the moment someone gets around to the reindex, and it’s the kind of gap an audit won’t catch unless a team actually runs the detection query Supabase is shipping alongside the patch. Projects leaning on ltree or btree_gist indexes for query correctness, not just speed, have the other bit of homework due before today’s default flip reaches them.