PgBouncer 1.26.1 修了三个高危漏洞：知道一个用户密码就能冒充超管

PgBouncer 1.26.1 修复三个高危漏洞，其中最严重的一个是：攻击者只要知道任意一个用户的密码，借助 SCRAM 认证流程就能冒充其他用户，甚至超级管理员登录。

这个漏洞为什么危险

连接池处在数据库最外层，几乎所有业务流量都经过它。一旦认证可被绕过，等于把整个库的入口交出去。

更麻烦的是利用门槛。不需要拿到管理员口令，一个普通业务账号的密码就够了，而这类密码在配置文件、环境变量、CI 变量里到处都是。

排查步骤

一，确认版本。所有 PgBouncer 实例都查，包括那些「很久没动过」的旁路实例。

二，看认证方式。用 auth_type 与 userlist 里的 SCRAM 配置，确认是否在受影响范围内。

三，限制暴露面。PgBouncer 不应该对公网开放，只允许应用网段访问，这一条能挡住绝大多数外部尝试。

四，轮换口令。如果实例曾暴露在不可信网络，把经过它的账号口令全部换掉。

五，查日志。关注异常的认证成功记录，尤其是低权限账号登录成高权限用户的痕迹。

升级本身不难

装包替换、重启进程，连接会短暂中断，建议在低峰做。难点在于清点范围，很多团队只知道主库前面有一个，实际上分库、报表库、只读库前各有一个。

一句话结论

这类组件平时无人关注，出事就是全站级。把它加进资产清单，配一个版本告警，成本很低。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

知道一个普通账号密码就能冒充超管，这个门槛太低了。PgBouncer 通常有好几个实例，分库、报表库、只读库前面各一个，清点范围千万别只查主库。

知道一个普通账号密码就能冒充超管，门槛低到可怕，而且这类实例通常没人盯着，装完就忘。我的处置顺序是先扫配置文件里的 auth_file 和 auth_query 用法，再确认有没有开宽松认证类型，最后才升版本。记得连旁路实例和读写分离中间件一起查。