PostgreSQL 2026 年 5 月安全更新：11 个 CVE 横扫所有受支持版本

Postgres 即将发布的小版本更新（v18.4 及所有受支持大版本的同批次小版本）携带着一份沉重的安全补丁清单——11 个 CVE，从 v14 到 v18 全线受影响。其中包含一个被评为 Critical 的路径穿越漏洞、多个 High 级别的内存溢出和 SQL 注入，以及一个能让攻击者通过认证握手把服务器打崩的 DoS 漏洞。官方 CVSS 评分和详细公告尚未发布，但从 git log 中已经可以拼出完整的风险地图。如果你是 DBA，现在就该排期打补丁了。

漏洞全景：四个类别，一个比一个棘手

内存与溢出：老代码里的暗雷

CVE-2026-6473（High）—— 内存溢出幽灵。 回补到 v14–v18。palloc_array() 的整数溢出边缘情况，这类漏洞在手工审计中极难捕捉——攻击者需要精确构造输入让分配大小绕过边界检查，随后写入越界内存。修复回补到了五年前的 v14，说明问题根植于非常早期的代码路径。

CVE-2026-6477（High）—— 前端大对象缓冲区越界。 同样回补到 v14–v18。影响 libpq 端的大对象操作，意味着客户端库本身也有风险，不只是服务端。

CVE-2026-6474（Medium）—— pg_strftime() 不安全处理。 回补到 v14–v18。时间格式化函数的边界问题，虽然评级 Medium，但在特定场景下可能被串联利用。

CVE-2026-6472（Medium）—— 多范围类型缺少 CREATE 权限检查。 回补到 v14–v18。多范围类型（multirange）是 v14 引入的特性，但权限检查一直缺失，意味着低权限用户可能通过该类型绕过预期限制。

复制与备份：最危险的一组

CVE-2026-6475（Critical）—— pg_basebackup 与 pg_rewind 中的路径穿越。 回补到 v14–v18。这是本次更新中唯一被评为 Critical 的 CVE。路径穿越意味着攻击者可以构造特殊的表空间路径，让备份工具写入到文件系统中的任意位置——覆盖配置文件、植入恶意二进制，或者窃取数据。如果你的备份流程由非超级用户触发，或者备份目标目录并非完全隔离，风险极高。

CVE-2026-6476（High）—— pg_createsubscriber 中的 SQL 注入。 回补到 v17–v18。pg_createsubscriber 是 v17 新引入的工具，用于将物理复制 standby 转换为逻辑复制订阅者。SQL 注入发生在该工具内部执行的命令构造环节。

CVE-2026-6638（High）—— 逻辑复制中的 SQL 注入。 回补到 v16–v18。逻辑复制的发布/订阅机制中存在注入点，攻击者可能通过精心构造的复制数据触发非预期 SQL 执行。

加密与 DoS：认证路径上的软肋

CVE-2026-6479（High）—— SSL/GSS 递归导致拒绝服务。 回补到 v14–v18。在处理启动包（startup packet）时，SSL 或 GSSAPI 认证握手可能触发递归调用，导致服务端崩溃。只要能连上 Postgres 端口的客户端就能发起攻击——不需要认证成功，只需要发送一个畸形的握手包。对于暴露在公网或多租户环境下的实例，这是最高优先级的修补项。

CVE-2026-6478（Medium）—— 认证时序攻击防御。 回补到 v14–v18。认证路径中存在可被利用的时序差异，攻击者通过精确测量响应时间可以缩小密码搜索空间。修复引入了恒定时间比较逻辑。

边缘情况：目录与 contrib 模块

CVE-2026-6637（High）—— refint contrib 模块漏洞。 回补到 v14–v18。refint 是一个较老的 contrib 模块，提供引用完整性触发器支持。如果你安装并使用了该扩展，升级后必须执行 ALTER EXTENSION refint UPDATE。

CVE-2026-6575（Medium）—— 统计信息恢复崩溃。 仅影响 v18。pg_restore 恢复统计信息目录时可能触发崩溃，范围有限但值得注意。

异常信号：回补深度创下历史纪录

这次更新最引人注目的不是单个 CVE 的严重程度，而是回补的整体模式。作者引入了一个"漏洞年龄积分"指标：每个 CVE 的回补范围越远（例如回补到 v14，v14 发布于 2021 年，计 5 分），积分越高；11 个 CVE 全部回补到 v14，理论最大值就是 55 分。

过去数年，这个指标长期徘徊在个位数——偶尔一个 CVE 回补到 v14，其余只影响较新版本。但本次更新直接把指标推到了前所未有的高度。这不是"某个研究员找到一个巧妙漏洞"的模式，更像是一次系统性、机器辅助的代码扫描——整数溢出、递归 bug、时序侧信道，这些正是自动化审计工具擅长捕捉的缺陷类型。

作者提出了一个大胆的猜测：AI 驱动的代码审计工具（如 Anthropic 的 Glasswing 项目）可能参与了这些漏洞的发现。Linux 内核维护者 Greg Kroah-Hartman 近期也公开承认，AI 提交的 bug 报告质量已经从"垃圾"进化到" genuinely 高质量"。无论这个猜测是否成立，数据本身已经说明问题——Postgres 的安全审计正在进入一个更密集、更深入的新阶段。

实战修补：停服务、换二进制、跑扩展更新

好消息是，这些都是小版本升级，不需要运行 pg_upgrade，也不需要转储/恢复数据。标准流程是：停库、换包、起库。但有几个细节容易踩坑。

基础升级流程（以 Debian/Ubuntu 为例）

# 1. 查看当前版本
psql -c "SELECT version();"

# 2. 停止 PostgreSQL（选择一种方式）
# 如果用 systemd：
sudo systemctl stop postgresql

# 如果用 pg_ctl：
pg_ctl -D /var/lib/postgresql/17/main stop

# 3. 升级包
sudo apt update
sudo apt install --only-upgrade postgresql-17 postgresql-client-17

# 4. 重启
sudo systemctl start postgresql

# 5. 确认版本号已更新
psql -c "SELECT version();"

对于 RHEL/CentOS 系列：

# 停库
sudo systemctl stop postgresql-17

# 升级
sudo yum update postgresql17-server postgresql17

# 重启
sudo systemctl start postgresql-17

扩展更新——最容易遗漏的步骤

如果你使用了受影响扩展（特别是 refint），升级二进制后必须在库内执行扩展更新：

-- 检查已安装的扩展版本
SELECT name, default_version, installed_version
FROM pg_available_extensions
WHERE installed_version IS NOT NULL;

-- 更新 refint 扩展（CVE-2026-6637 修复要求）
ALTER EXTENSION refint UPDATE;

-- 如果使用了其他受影响扩展，也一并更新
ALTER EXTENSION lo UPDATE;  -- 大对象相关，CVE-2026-6477

针对高危场景的优先级排序

如果你的实例满足以下条件，应该把修补优先级提到最高：

升级前的快速自检脚本

在正式升级前，可以用以下脚本快速评估你的实例是否命中高危场景：

#!/bin/bash
# pg_security_check.sh — 升级前自检
PG_USER="postgres"
PG_HOST="/var/run/postgresql"

echo "=== PostgreSQL 2026-05 Security Pre-Check ==="

# 当前版本
echo -n "Current version: "
psql -U "$PG_USER" -h "$PG_HOST" -t -c "SELECT version();" 2>/dev/null | head -1

# 检查是否有不受信任的网络访问
echo -n "Listen addresses: "
psql -U "$PG_USER" -h "$PG_HOST" -t -c "SHOW listen_addresses;" 2>/dev/null | head -1

# 检查 SSL 状态
echo -n "SSL enabled: "
psql -U "$PG_USER" -h "$PG_HOST" -t -c "SHOW ssl;" 2>/dev/null | head -1

# 检查逻辑复制订阅
echo "Logical replication subscriptions:"
psql -U "$PG_USER" -h "$PG_HOST" -t -c \
  "SELECT subname, subconninfo FROM pg_subscription;" 2>/dev/null

# 检查 refint 扩展
echo "refint extension status:"
psql -U "$PG_USER" -h "$PG_HOST" -t -c \
  "SELECT name, installed_version FROM pg_available_extensions WHERE name='refint';" 2>/dev/null

# 检查大对象使用情况
echo "Large object count:"
psql -U "$PG_USER" -h "$PG_HOST" -t -c \
  "SELECT count(*) FROM pg_largeobject_metadata;" 2>/dev/null | head -1

echo "=== End of check ==="

运行方式：

chmod +x pg_security_check.sh
./pg_security_check.sh

修补的风险权衡

作者有一句话值得反复引用：不修补的风险远大于升级本身的风险。 这不是空话——小版本升级在 Postgres 生态中是经过严格回归测试的，数据目录格式不变，客户端协议不变，唯一的变化是二进制中的 bug 修复。相比之下，一个 Critical 级别的路径穿越漏洞留在生产环境里，等于给攻击者留了一扇随时可以推开的门。

有几个注意事项：

• 读发布说明。 每个小版本的 release notes 会列出所有行为变更，特别是涉及目录对象或扩展的修复，可能要求额外的 SQL 操作。
• 备份验证。 升级前确认最近的 pg_basebackup 或逻辑备份可以正常恢复——这本身就是对 CVE-2026-6475 的间接验证。
• 测试环境先行。 如果你有 CI/CD 管线或 staging 环境，先在那里升级并跑一遍核心查询和复制链路。
• 关注官方公告。 NVD 和 postgresql.org 的正式 CVSS 评分和详细 advisory 即将发布，评分可能与当前估计有差异，调整优先级时以官方为准。

Postgres 的安全审计正在变得更深入、更系统化。无论这背后是否有 AI 工具的参与，对运维者来说信号是一样的：旧版本不再意味着"稳定且安全"，五年前的代码路径同样可能藏着 Critical 级别的缺陷。定期打小版本补丁，已经不是可选操作，而是基本运维纪律。