Empty search_path in amcheck. A grantee of amcheck function EXECUTE privilege could execute arbitrary functions as the owners of expression indexes that depend on the search path. An expression like (lower(col)) was not vulnerable, because lower() is resolved at CREATE INDEX time. However, an expression calling an sql-language or plpgsql-language function often was vulnerable, even if it used search_path only to find objects in pg_catalog. The amcheck documentation has been warning about data disclosure after such a GRANT, not about function execution.
This might cause new amcheck errors when index expressions rely on a broader search_path. Such indexes have seen errors during auto-analyze since CVE-2018-1058 commit 582edc369cdbd348d68441fc50fa26a84afd0c1a, and v17 amcheck always worked this way. Hence, the risk is low. Leave a comment on the one other sandbox entrance that doesn't empty search_path. In its case, the choice was valid. Back-patch to v14 (all supported versions), but v17 was safe already. Commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17) unintentionally blocked the attack, and commit d70b17636ddf1ea2c71d1c7bc477372b36ccb66b (v18) unintentionally removed that protection. Hence, this adds to v17 just a test and a comment. While emptying search_path became more widespread in commit 2af07e2f749a9208ca1ed84fa1d8fe0e75833288 (v17), none of its other changes blocked an attack available in v16, even when considering GRANT. For example, brin_summarize_range() has had an owner check that GRANT does not override. Reported-by: 王跃林 <[email protected]> Reported-by: Jacob Brazeal <[email protected]> Backpatch-through: 14 Security: CVE-2026-14673 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/39d792040c7cc02b8a805b96b718e723a15f1641 Modified Files -------------- contrib/amcheck/expected/check_btree.out | 17 +++++++++++++++-- contrib/amcheck/sql/check_btree.sql | 18 +++++++++++++++--- contrib/amcheck/verify_nbtree.c | 2 ++ 3 files changed, 32 insertions(+), 5 deletions(-)
