PgBouncer 1.25.2：一个未认证 TCP 连接就能打垮你的连接池，本周必须升级

预计阅读时间：7 分钟

PgBouncer 1.25.2 刚发布了一个关键补丁，修复了 CVE-2026-6664——一个预认证阶段的崩溃漏洞。这意味着攻击者不需要任何凭据，只要能向 PgBouncer 监听端口发起一条精心构造的 TCP 连接，就能让整个连接池进程直接崩溃。如果你的生产环境用 PgBouncer 做 PostgreSQL 的连接池，这不是"有空再看看"的级别，而是本周必须动手的级别。

漏洞本质：认证之前就已经在处理连接

PgBouncer 的工作流程是：客户端连接 → 认证 → 分配后端数据库连接。CVE-2026-6664 的触发点在认证之前的连接处理阶段。换句话说，攻击者根本不需要知道数据库用户名或密码，只需要能触达 PgBouncer 的监听端口。

这带来的直接后果：

单连接即可崩溃：不是需要大量连接慢慢耗尽资源，而是一条请求就能让进程退出。
所有后端连接丢失：PgBouncer 进程崩溃后，它管理的所有到 PostgreSQL 的后端连接全部断开，正在执行的查询会被中断。
自动恢复未必可靠：即使你有 systemd 自动拉起，崩溃-恢复-崩溃的循环足以让服务处于不可用状态。

影响范围与风险评估

这个漏洞影响所有低于 1.25.2 的 PgBouncer 版本。需要重点关注的场景：

场景	风险等级	说明
PgBouncer 端口暴露在公网	极高	任何人都能直接发送恶意连接
PgBouncer 端口仅内网可达	高	内网被渗透后可被利用做拒绝服务
PgBouncer 端口仅本机可达	中	应用层漏洞可能被链式利用

一个常见误区是"PgBouncer 只在内网用就安全"。内网中的任何容器、任何被入侵的开发机、任何有网络访问权限的服务，都可能成为攻击源。CVE-2026-6664 的门槛太低了——不需要认证、不需要持久连接、不需要复杂协议交互。

升级实操：从检测到部署

下面是一套可以直接复制执行的升级流程。

第一步：确认当前版本

# 查看正在运行的 PgBouncer 版本
pgbouncer --version

# 或者通过进程信息确认
ps aux | grep pgbouncer

如果输出显示版本低于 1.25.2，就需要升级。

第二步：从官方源安装 1.25.2

不同系统的安装方式不同，以下是最常见的几种：

# Debian/Ubuntu — 使用 PostgreSQL 官方 APT 源
sudo apt update
sudo apt install pgbouncer=1.25.2*

# RHEL/CentOS — 使用 PostgreSQL 官方 YUM 源
sudo yum install pgbouncer-1.25.2

# 从源码编译（适用于自定义安装路径的场景）
wget https://www.pgbouncer.org/downloads/files/1.25.2/pgbouncer-1.25.2.tar.gz
tar xzf pgbouncer-1.25.2.tar.gz
cd pgbouncer-1.25.2
./configure --prefix=/usr/local
make
sudo make install

第三步：验证配置兼容性后重启

# 先用 --check 验证配置文件语法没有问题
pgbouncer --check /etc/pgbouncer/pgbouncer.ini

# 确认无误后重启服务
sudo systemctl restart pgbouncer

# 验证新版本已生效
pgbouncer --version
# 期望输出: PgBouncer 1.25.2

第四步：确认连接池恢复正常

# 通过 admin socket 检查连接池状态（配置中需要开启 admin_users）
psql -h 127.0.0.1 -p 6432 -U pgbouncer pgbouncer -c "SHOW POOLS;"
psql -h 127.0.0.1 -p 6432 -U pgbouncer pgbouncer -c "SHOW DATABASES;"

SHOW POOLS; 应该能看到客户端连接和后端连接的正常映射，SHOW DATABASES; 应该显示各数据库的连接状态为 OK。

升级前的临时缓解措施

如果本周内无法完成升级（比如需要走变更审批流程），可以先部署以下缓解措施降低被攻击概率：

网络层隔离——只允许可信来源访问 PgBouncer 端口

# 示例：使用 iptables 限制只有应用服务器能连接 PgBouncer 的 6432 端口
# 假设应用服务器 IP 为 10.0.1.0/24，PgBouncer 运行在本机

sudo iptables -A INPUT -p tcp --dport 6432 -s 10.0.1.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 6432 -j DROP

# 保存规则
sudo iptables-save > /etc/iptables/rules.v4

Kubernetes 环境下的 NetworkPolicy

如果你的 PgBouncer 部署在 K8s 中，用 NetworkPolicy 限制入站流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: pgbouncer-ingress
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: pgbouncer
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: my-application
      ports:
        - protocol: TCP
          port: 6432

这些措施不能替代升级——它们只是缩小了攻击面。漏洞本身仍然存在，任何被允许连接的来源如果被攻破，仍然可以触发崩溃。

升级后的检查清单

升级完成后，逐项确认：

[ ] pgbouncer --version 输出为 1.25.2 或更高
[ ] pgbouncer --check 配置文件无报错
[ ] SHOW POOLS; 显示正常连接映射
[ ] SHOW DATABASES; 各数据库状态正常
[ ] 应用层连接数据库的功能测试通过
[ ] PgBouncer 日志中无异常错误（journalctl -u pgbouncer --since "1 hour ago"）
[ ] 防火墙或 NetworkPolicy 已配置，PgBouncer 端口不暴露给不必要的来源

CVE-2026-6664 的攻击成本极低、影响面极大——一条 TCP 连接就能让整个连接池宕机，连带所有后端查询中断。升级到 PgBouncer 1.25.2 是目前唯一的根本修复方案，临时缓解只能缩小攻击窗口，不能消除漏洞本身。本周动手，不要拖到下周。