2026 年 5 月 14 日，PostgreSQL 同时发布五个版本：18.4、17.10、16.14、15.18、14.23。这次更新修补了 11 个安全漏洞和超过 60 个一般缺陷。11 个 CVE 是 PostgreSQL 历史上单次发布最大的安全补丁批次，其中三个评分达到 CVSS 8.8，且具备可被实际利用的攻击路径——不是理论风险，是有人能打进去的那种。
为什么这次补丁量这么集中
PostgreSQL 的安全修复通常分散在各次小版本中，单次发布 2–3 个 CVE 已经算多。11 个 CVE 集中释出，最可能的解释是：部分漏洞在内部或外部审计中被关联发现，属于同一攻击面的不同切入点；另外一些可能是在准备修复某个高危问题时，顺带揭开了相邻代码中的隐患。三个 8.8 分漏洞共享"可实际利用"这一标签，说明攻击者不需要特殊环境或罕见配置就能触发它们。
你最该关注什么
CVSS 8.8 在 PostgreSQL 的语境里通常指向以下几类问题：
- 认证绕过或权限提升——低权限用户通过特定查询序列获得超户能力。
- 协议层攻击——利用连接握手或 SSL 协商阶段的缺陷，在未认证状态下造成拒绝服务或信息泄露。
- 内置函数的边界错误——某些聚合或窗口函数在极端输入下触发内存越界，可被用于执行任意代码。
虽然具体 CVE 编号和细节在官方公告中才会完整披露，但 8.8 + "practical exploitation" 这个组合意味着：如果你的 PostgreSQL 实例暴露在不可信网络（哪怕是内网中其他团队可访问的端口），这些漏洞就不是"有空再修"的级别。
快速自查：你的实例暴露面有多大
下面这个脚本可以帮你快速梳理当前 PostgreSQL 的版本和暴露情况。在运行前，把 PGHOST、PGPORT、PGUSER 替换成你自己的连接参数。
#!/usr/bin/env bash
# pg_security_check.sh — 快速检查 PostgreSQL 版本与暴露面
# 使用前确保 psql 已安装，且目标实例允许连接
PGHOST="${PGHOST:-localhost}"
PGPORT="${PGPORT:-5432}"
PGUSER="${PGUSER:-postgres}"
echo "=== PostgreSQL 版本 ==="
psql -h "$PGHOST" -p "$PGPORT" -U "$PGUSER" -t -c "SELECT version();" | head -1
echo ""
echo "=== 监听地址 ==="
psql -h "$PGHOST" -p "$PGPORT" -U "$PGUSER" -t -c \
"SELECT name, setting FROM pg_settings WHERE name = 'listen_addresses';"
echo ""
echo "=== 监听端口 ==="
psql -h "$PGHOST" -p "$PGPORT" -U "$PGUSER" -t -c \
"SELECT name, setting FROM pg_settings WHERE name = 'port';"
echo ""
echo "=== SSL 配置 ==="
psql -h "$PGHOST" -p "$PGPORT" -U "$PGUSER" -t -c \
"SELECT name, setting FROM pg_settings WHERE name IN ('ssl', 'ssl_cert_file', 'ssl_key_file', 'ssl_ca_file');"
echo ""
echo "=== 活跃连接数 & 来源 ==="
psql -h "$PGHOST" -p "$PGPORT" -U "$PGUSER" -t -c \
"SELECT client_addr, count(*) FROM pg_stat_activity GROUP BY client_addr ORDER BY count(*) DESC LIMIT 10;"
echo ""
echo "=== 具有超级权限的角色 ==="
psql -h "$PGHOST" -p "$PGPORT" -U "$PGUSER" -t -c \
"SELECT rolname, rolsuper FROM pg_roles WHERE rolsuper = true;"
运行方式：
chmod +x pg_security_check.sh
./pg_security_check.sh
重点关注输出中的：
- 版本号是否低于本次发布的新版本；
- listen_addresses如果是 *，说明实例监听所有网卡，暴露面最大；
- 超级角色列表越少越好，应用服务不应使用超户连接。
升级路径与操作要点
PostgreSQL 小版本升级（比如 17.8 → 17.10）不需要 dump/restore，只需替换二进制后重启。但 11 个 CVE 的修补量意味着变更比平时大，建议按以下步骤操作：
# 1. 在升级前确认当前数据目录兼容新版本
pg_controldata /var/lib/postgresql/17/main | grep "Database system identifier"
# 2. 停止实例
sudo systemctl stop postgresql@17-main
# 3. 升级包（Debian/Ubuntu 示例，其他发行版用对应包管理器）
sudo apt update && sudo apt install --only-upgrade postgresql-17
# 4. 启动并验证版本
sudo systemctl start postgresql@17-main
psql -c "SELECT version();"
如果你跑的是容器化部署，拉取新镜像后重新启动即可：
docker pull postgres:17.10
docker stop my-postgres
docker rm my-postgres
docker run -d --name my-postgres \
-v pgdata:/var/lib/postgresql/data \
-e POSTGRES_PASSWORD=your_password \
postgres:17.10
注意：容器场景下数据卷挂载路径必须与原容器一致，否则新容器会初始化一个空数据库。
升级前的风险控制
三个 8.8 分漏洞可被实际利用，但升级本身也有风险——超过 60 个缺陷修复可能引入行为变化。建议：
- 先在 staging 环境升级，跑一遍核心业务查询和写入流程，观察是否有回归。
- 生产升级选择低流量时段，并保留回滚能力：不要同时删除旧版本二进制，确认新版本稳定后再清理。
- 升级后立即检查日志：
pg_log中出现新的 ERROR 或 PANIC 是最直接的异常信号。 - 如果暂时无法升级，至少把
listen_addresses收窄到只监听应用服务器可达的内网接口，并确保 SSL 开启。这不能消除漏洞，但能缩小攻击面。
检查清单
| 项目 | 状态 |
|---|---|
| 当前版本是否 ≥ 本次发布的新版本 | ☐ |
listen_addresses 是否不是 * |
☐ |
| SSL 是否启用且证书有效 | ☐ |
| 应用连接是否使用非超户角色 | ☐ |
| staging 环境已完成升级验证 | ☐ |
| 生产升级已安排低流量时段 | ☐ |
| 升级后 pg_log 无新 ERROR/PANIC | ☐ |
11 个 CVE 集中释出在 PostgreSQL 的历史上没有先例。三个 8.8 分漏洞具备实际利用路径，这不是可以拖到下个季度再处理的更新。查版本、缩暴露面、安排升级——这三步今天就可以开始。