一句话结论：2026 年 8 月 13 日 PostgreSQL 发布的安全更新里，CVE-2026-15742 是个 CVSS 8.8 的高危 RCE。触发条件很具体——装了 fuzzystrmatch 扩展，且版本低于修复线。先花 30 秒自查，再决定是升级还是直接 DROP EXTENSION。

1. 漏洞是怎么回事

问题出在 contrib 模块 fuzzystrmatch 的 levenshtein() / levenshtein_less_equal() 函数：整数回绕（integer wraparound）导致任意地址写入，最终能以 PostgreSQL 操作系统用户的身份执行任意代码。

翻译成 DBA 能听懂的话：

  • 不需要操作系统账号，只要能连上数据库执行 SQL 就可能触发；
  • 炸的是 postgres 这个 OS 用户，数据库服务器基本就交代了；
  • 但前提是目标库装了 fuzzystrmatch——这个扩展很多人装完就忘了。

2. 影响版本

官方修复线（低于以下版本即受影响）：

大版本 修复版本
18 18.6
17 17.11
16 16.15
15 15.19
14 14.24
13 及以下 已 EOL，全部视为受影响

注意 13 及以下已经 EOL，官方不会再出补丁，还在跑的要么升级要么自求多福。

3. 自查：两条 SQL + 一个 shell 循环

1
2
3
4
5
-- 查版本
SELECT version();

-- 每个库执行：有返回就说明装了 fuzzystrmatch
SELECT * FROM pg_extension WHERE extname = 'fuzzystrmatch';

实例上库多的时候，一个个连太费劲，直接循环：

1
2
3
4
5
for db in $(psql -tAc "SELECT datname FROM pg_database WHERE datistemplate = false"); do
  hit=$(psql -d "$db" -tAc "SELECT count(*) FROM pg_extension WHERE extname='fuzzystrmatch';")
  [ "$hit" != "0" ] && echo "库 $db 装了 fuzzystrmatch"
done
psql -tAc "SELECT version();"

装了扩展 + 版本低于修复线 = 中招条件拉满。

4. 处置

  1. 首选升级：升到上面表格里的修复版本。小版本升级一般不需要 dump/restore，但升级前先看 release notes，备库先升、主库后升。
  2. 不能马上升级：评估业务是否真的在用 levenshtein() 这类函数，不用就 DROP EXTENSION fuzzystrmatch;——扩展删了，攻击面就没了。
  3. 纵深防御：复查数据库账号权限，别给业务账号超纲的权限；网络层限制能直连数据库的主机。

5. 顺手的事

我们在 DBAClaw 的 PG 巡检引擎里已经加了这条规则：装了 fuzzystrmatch 且版本低于修复线就报”高/安全”告警，版本解析不出来时不误报。巡检跑一遍，全实例有没有中招一目了然。

参考：

原文作者: liups.com

原文链接: http://liups.com/posts/3c95b736/

许可协议: 知识共享署名-非商业性使用 4.0 国际许可协议