一次更新，52 个安全漏洞。PostgreSQL 全球开发组昨天放出的补丁包里，最扎眼的是 CVE-2026-6460 ——一个能让数据库用户直接在服务器上跑代码的类型混淆漏洞，CVSS 评分8.8。

这个漏洞的根，能追到 2004 年 5 月 5 日。那天 PostgreSQL 获得了修改列类型的能力。安全研究员 Mehmet Ince 在技术分析里把源头指向这一天，而他真正用来执行代码的手法，依赖的是 2015 年 5 月 14 日的另一次改动。

漏洞出在复合类型上。复合类型由带名字的字段拼成，每个字段有自己的数据类型。问题在于，字段的类型可以被改掉，而服务器其他位置还留着这个字段的旧值。服务器随后会把旧值当成新类型来读，类型对不上，代码就可能被执行。

项目在发布说明里给出的修法是加版本检查，让服务器能识别出已经不匹配类型的值。任何以这种方式跑起来的代码，都拥有运行 PostgreSQL 那个操作系统用户的权限。

Ince 在 PostgreSQL 18.6 上演示了可用的利用方式。他的步骤是：先准备一个持有值的查询，改掉值里某个字段的类型，再执行这个查询。分析里附了能让未打补丁的服务器崩溃的 SQL，以及第二步泄露内存地址的 SQL。最后一步让服务器执行命令的 SQL 没有公开。

他写道，自己可以 " 用最低权限的登录角色触发这次崩溃 "。项目的安全公告只把攻击者描述为能创建对象的人，没有说明这需要哪些具体权限。红帽在其 CVE 评估中表示，攻击者需要一个能创建或修改对象的数据库登录账号。这些来源都没有说明，只有默认权限的账号能否越过崩溃这一步去执行代码。

Ince 还把利用方式适配到了托管 PostgreSQL 服务上，并在 8 月私下向这些服务的安全团队分享了概念验证。合作过的服务商包括 AWS（Aurora 和 RDS）、微软（Azure PostgreSQL）、谷歌（AlloyDB）、Supabase、Databricks 和 Ubicloud。分析里没有给出各家服务当前的补丁状态。

受影响的是 18.7、17.12、16.16、15.20 和 14.25 之前的全部版本。项目没有报告任何利用该漏洞的攻击，CISA 在 CVE 记录中的评估也把利用状态列为无。

52 个漏洞里，有32 个被评为 8.8 分，是本次发布中的最高分。按项目漏洞索引里的评分，服务器端只有一个漏洞既不需要登录、也不需要任何用户操作：CVE-2026-116322，未认证的客户端可以触发 PostgreSQL 18 服务器重启。

客户端工具也修了几处。一个精心构造的归档文件能让 pg_restore 以运行它的用户身份执行代码；一台被攻陷的源服务器能通过 pg_dump 的 tar 输出里的恢复脚本，让 psql 执行代码。

管理员要做的动作不少：

按主版本号把服务器更新到 18.7、17.12、16.16、15.20 或 14.25。

同时重建或更新所有 C 语言扩展。按旧版本编译的扩展仍能加载，但项目 RPM 包维护者在仓库通知里说，它们 " 可能不受本次发布所修漏洞的保护 "。部分扩展还需要改源码。

为新版本重建的扩展，可能在旧服务器上加载失败。项目 RPM 仓库里的扩展包现在要求新的小版本。

如果 PostgreSQL 跑在包自带服务单元之外，比如在 Patroni 下，更新后要立刻重启——这是 RPM 包维护者在打包博客里说的。

每台运行 pg_dump、pg_restore、reindexdb、vacuumdb 的机器，都要更新这些客户端工具。

不要用新的 composite_type_mismatch 设置关掉检查，项目说这么做有安全风险。

对于暂时无法更新的服务器，公告和发布说明都没有给出变通方案。

PostgreSQL 14 已停止支持，14.25 是它的最后一个版本。更老的主版本同样受影响，且没有获得更新。

更新后按发布公告里的步骤重建索引。如果用增量备份，先做一次新的全量备份，后续增量备份以它为基础。

项目为 CVE-2026-6460 致谢了十几位报告者，Ince 在列，同一次发布中另外五个漏洞也记了他的名字。