PostgreSQL 修复大量漏洞，云厂商坐不住了

PostgreSQL 发新版，包含大量高危漏洞的修补，云厂商可能坐不住了。

来看看咋回事，PG 18.7、17.12、16.16、15.20、14.25，一口气修了52个安全漏洞、140多个Bug。你要搁两三年前，谁会相信PostgreSQL在一个小版本里能爆出52个CVE？这不符合常理啊，PG社区一直是稳扎稳打的代名词。但世界变了。

这52个补丁怎么来的？AI驱动的漏洞挖掘工具把开源软件的攻击面给“降维打击”了。像这次那个CVE-2026-6460，类型混淆导致任意代码执行，CVSS 8.8，报告人里赫然出现了OpenAI和Anthropic的安全团队。你品品这个信号——以前是安全研究员手工挖洞、报洞，现在是AI程序化地扫描源码，自动生成PoC。Phoronix那篇报道直接就说了，说PG开发者被AI/LLM驱动的bug报告给“锤”了，连PG 19的发布都因此延期。

AI把漏洞发现成本打到了地板价，导致漏洞报告的洪流漫灌到社区，PG核心组只能硬着头皮把过去积压的、深藏的那些边界问题一次性全兜出来。你看到的是52个CVE，底下是这几个月被AI工具翻了个底朝天的代码库。

那这52个补丁的成色怎么样？你翻那个安全列表，大量的use-after-free、type confusion、buffer overflow，而且很多触发条件都要求“对象创建权限”或者“已认证用户”。这说明什么？说明这些漏洞的利用门槛并不低，不是那种挂到公网上就能被脚本小子打穿的RCE。很多漏洞的杀伤力在于权限提升，比如数据库里的一个普通用户，通过类型混淆或者释放后重用，能把代码执行权限捅到数据库OS用户那一级。对于云厂商来说，这才是最要命的——因为云上PG默认就是把客户限制在数据库内部，不给你OS权限。一旦有客户利用这些漏洞把OS给穿了，那就是跨租户的灾难。所以CVE-2026-6460这种漏洞，云厂商的修复优先级一定拉满，跟那些需要一堆前置条件的漏洞完全是两码事。

再注意看PGDG RPM仓库的公告：这次 extension 也必须跟内核一起升级。为什么？因为CVE-2026-6460的修复改变了复合类型的存储格式，也改了服务端给扩展的接口。旧扩展跑在新内核上，能加载，但没有安全防护；新扩展跑在旧内核上，直接报“undefined symbol”加载失败。这意味着：下游的分发厂商没法只发内核不发扩展。像RHEL、Rocky、Alma这些用PGDG源的用户，dnf update必须一把梭，不能挑挑拣拣。你要是用versionlock把内核锁住，扩展也升不上去，等于安全补丁没打全。这就把“补丁管理”从单纯的“升内核”变成了“升整套供应链”。

分发厂商现在最头疼的不是编译内核，而是扩展生态的连锁反应。PostGIS 3.7.0直接把两个伴生扩展踢出核心包独立分发，这就是典型的“收缩攻击面”策略。若航那篇文章里说得很形象，AI满地找洞的时代，主动剥离非核心组件是明智之举。分发厂商的对策就是两条路：要么像PGDG这样，把扩展和内核的依赖关系卡死，逼着用户一起升；要么像PostGIS这样，把高风险扩展拆出去，让需要的人自己承担维护责任。没有第三条路，因为AI不会停下扫描的脚步。

云厂商的对策更微妙。云上RDS的补丁节奏，永远是“全托管、滚动升级、用户无感”。但这次不一样，因为很多漏洞的触发条件就是“对象创建权限”，而云上用户恰恰有这个权限——你总不能不让用户建表建类型吧？所以云厂商的补丁窗口会压得非常紧。更关键的是，像CVE-2026-116313这种vacuumdb的漏洞，数据库所有者能利用它执行代码，云厂商的后台运维工具如果直接跑在客户实例上，那就成了攻击跳板。所以云厂商的逻辑是：不仅自己要升，还要确保客户的扩展也升到位。因为云厂商托管的PG，扩展版本是跟着内核走的，客户没得选。这反而成了云上环境的优势——补丁一致性比自建环境好管控得多。

最后说一嘴PG 14的EOL。这次14.25是最后一版，之后不再有安全修复。还在跑14的生产环境，要么升大版本，要么就裸奔。而升大版本的窗口期，恰恰撞上了这波AI驱动的漏洞洪流。所以我的判断是，接下来半年，PG 14到15/16的迁移咨询量会暴增。

AI改变了漏洞发现的成本曲线，而成本曲线的变化，最终会传导到每一个DBA的升级日历上。躲不掉的。