PostgreSQL 是运维团队最信任的关系型数据库之一，但它的权限模型里藏着一些"看起来够用、实则危险"的角落。2026 年 8 月 13 日随 18.6/17.11 等版本一起修复的 CVE-2026-6471，恰好踩在这类角落上：一个拥有 REPLICATION 复制权限、但并非超级用户的账号，可以通过逻辑解码（logical decoding）选择让数据库用 dlopen 加载一个服务器端可见的任意文件，从而以运行数据库服务的系统用户身份执行任意代码。CVSS 3.0 为 7.2，属于权限绕过导向远程代码执行。
一、根因：复制权限被高估成"只读"
PostgreSQL 的逻辑解码用于监控或读取数据库变更流，本意是给支持流式消费者的账号提供一种只读的访问方式。CVE-2026-6471 的问题在于，逻辑解码插件的加载缺少必要的授权检查：拥有 REPLICATION 权限的非超级用户，可以指定一个任意输出插件（output plugin），让数据库服务器用 dlopen 去加载那个插件对应的共享库文件。既然触发点落在"加载任意共享库"，后果就不止于读数据——它意味着攻击者可以在数据库服务进程的用户上下文里执行任意代码。对很多把 PostgreSQL 与业务、乃至操作系统同一账号部署的环境来说，这一步就直接通往服务器层面的权益。
二、修复与时序：一个白名单参数的新增
官方在 18.6 里引入了一个名为 output_plugin_libraries 的新参数，用来限制逻辑解码输出插件可以从哪些库加载，从"任意"收窄到"明确白名单"，从而把漏洞暴露面收掉。此次修复一并落到 17.11、16.15、15.19、14.24，覆盖了广泛部署的既有主版本。值得强调的是，这类"授权检查缺失导致越权 RCE"的漏洞，在数据库上的杀伤力并不亚于某些 Web 漏洞——因为它直接接触到最敏感的数据存储，一旦被利用，后果往往直指数据完整性与服务器控制权。
三、为什么值得每个 PG 管理员上心
PostgreSQL 几乎是互联网的基石级组件，而复制权限（REPLICATION）在很多团队里被当作"给只读副本用的账号"，被授予的范围往往大于应当的范围。CVE-2026-6471 提醒我们，数据库权限的每一项能力都需要按最小化原则收敛——尤其当它涉及"能加载代码""能写文件"这类底层能力时。即便当前没有检索到 KEV 确认它在野，一个影响到全部主流主版本、且能导向 RCE 的缺陷，也足以被列入高危清单。
四、处置与缓解
- 升级 PostgreSQL 至 18.6/17.11/16.15/15.19/14.24 及以上，这是根治手段；
- 审计 REPLICATION 权限的授予范围，确认哪些账号真的需要复制能力，收回多余授权；
- 关注新增的 output_plugin_libraries 参数并配置白名单，限制逻辑解码插件的加载来源；
- 排查数据库服务进程的运行用户，避免以高权限系统用户或与其它服务共享账号的方式运行 PostgreSQL。
CVE-2026-6471 留下的，是一条关于数据库权限的朴素提醒：即便一个账号"名义上只读"，只要它还握有能影响"如何加载代码"的开关，就可能被用来撬动整台服务器。把数据库的每一项细粒度权限都当成真实的攻击面来治理，才是这类漏洞真正教给运维者的功课。
参考：PostgreSQL 官方安全公告（CVE-2026-6471）、PostgreSQL 18.6 等版本的发布说明。