2026-08-23 04:58:59 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： PostgreSQL8月安全更新修复两个高危漏洞。CVE-2026-6471允许有REPLICATION权限的普通用户通过逻辑解码加载任意动态库实现远程代码执行。CVE-2026-6464在特定条件下使psql客户端将数据行误作命令执行。建议立即升级至安全版本并收紧REPLICATION权限。 综合评分： 85 文章分类： 漏洞分析,漏洞预警,应用安全

cover_image

紧急预警 | CVE-2026-6464 / 6471 | PostgreSQL 双洞齐发：一个能让你执行任意代码，一个让你的 psql 反被数据行指挥

撅人

2026年8月16日 00:00 广东

在小说阅读器读本章

去阅读

管数据库的、做DBA的，都看过来！

PostgreSQL 8 月季度安全更新一次性修了两个有意思的洞：CVE-2026-6471 逻辑解码 dlopen 任意文件——有 REPLICATION 权限的普通用户就能以 postgres 系统账号身份执行任意代码；CVE-2026-6464 psql 客户端被服务器”教唆”把数据行当命令执行。

前者直奔 RCE，后者玩的是”客户端被反向操控”的花活。所有还在跑 18.5 / 17.11 / 16.15 / 15.19 / 14.24 之前版本的同学，这次更新没得躲。

📋 漏洞速览

💥 核心危害：攻击者能做什么？

1️⃣ CVE-2026-6471：REPLICATION 权限 = 服务器账号的钥匙

逻辑解码（logical decoding）允许指定解码插件——本质是一个动态库，服务端会 dlopen 它。问题在于：选哪个插件竟然不查你是不是超级用户！

于是一个只有 REPLICATION 权限的普通账号（很多公司为了搭 CDC、搭数据同步，把 REPLICATION 权限发得像传单一样）可以：

指定一个攻击者可控路径的 .so 文件
让 postgres 服务端 dlopen 它
代码以 postgres 操作系统账号身份运行——读配置、改数据目录、往外发数据，想干嘛干嘛

数据库权限模型辛辛苦苦划的”普通用户/超级用户”边界，在 OS 层面被一脚踹开。

2️⃣ CVE-2026-6464：你的 psql 开始”听数据的话”

\copy FROM STDIN 或 COPY FROM STDIN 失败得太早——早到服务器还没说”我等你的数据行”——psql 就会把本来该当数据的行，当成 psql 命令来执行。

攻击剧本：恶意/被攻陷的 PostgreSQL 服务器 + 你脚本里内联的数据行，两者凑齐，数据行里的 \! rm -rf ... 这类元命令就执行了。带文件名的 COPY FROM 不受影响。

官方也说了：光控制服务器还不够，还得控制数据行，或者赌一个刚好踩中的偶发错误——利用门槛不低，但”客户端把数据当代码”这个性质本身就够恶心，尤其那些拿 psql 跑自动化脚本的 CI 流水线。

🧠 漏洞原理（人话版）

6471 —— 动态库加载没设门禁

逻辑解码插件走的是 dlopen 路线。正常理解里，加载任意路径的动态库并执行其代码，这种能力应该锁死在超级用户手里。但实现上，创建逻辑复制槽时指定 plugin 参数只检查了 REPLICATION 权限。REPLICATION 本意是”允许你订阅变更流”，结果顺手把”让服务器加载执行任意 .so”也打包送了出去。

6464 —— 错误来得太早，状态机走岔了

psql 处理 COPY FROM STDIN 的正常流程：发命令 → 服务器回复”CopyInResponse”（我准备好了，发数据吧）→ psql 把后面的行当数据发过去。但如果服务器在 CopyInResponse 之前就报错，psql 的解析状态机没退回”数据模式”，于是把脚本里紧跟着的内联数据行，交给了元命令解析器——\!、\i、\set 这些以反斜杠开头的指令，全部生效。

攻击流程 3 步走（6471）：

攻击者拿到一个带 REPLICATION 权限的普通账号（内部低权限用户 / 泄露的同步账号）
在服务器 OS 账号可读的位置放一个恶意 .so（借助 COPY 写文件、共享目录等）
创建逻辑复制槽并指定该 .so 为解码插件 → 服务端 dlopen → 代码以 postgres 账号运行

🔍 3 秒自查

红区（中招）：

| 大版本 | 安全版本（低于此=中招） | | — | — | | PostgreSQL 18 | 18.5 | | PostgreSQL 17 | 17.11 | | PostgreSQL 16 | 16.15 | | PostgreSQL 15 | 15.19 | | PostgreSQL 14 | 14.24 |

连上库一句话看版本：

psql -c “SELECT version();”

再查谁有 REPLICATION 权限（6471 的攻击门票，重点排查对象）：

psql -c “SELECT rolname, rolreplication, rolsuper FROM pg_roles WHERE rolreplication OR rolsuper;”

清单里出现的非超级用户、离职同事的遗留账号、第三方同步工具的账号——逐个过一遍：还该有吗？权限收得回来吗？

🛠️ 修复方案

方案一：升级到对应分支的安全版本（根治，强烈推荐）

各分支只需小版本升级，不涉及大版本迁移，风险低：

Debian/Ubuntu

apt update && apt install –only-upgrade postgresql-17

RHEL/CentOS

yum update postgresql-server

源码或二进制安装的，到官网下载对应分支最新版：https://www.postgresql.org/download/

注意：psql 客户端也要一起升！ CVE-2026-6464 是客户端洞，只升服务端不升客户端等于白干。运维机、跳板机、CI 镜像里的 psql 全部清一遍。

方案二：临时缓解（升级窗口前的止血带）

收紧 REPLICATION 权限：ALTER ROLE xxx NOREPLICATION;，只留给真正跑逻辑复制的账号
审计 pg_hba.conf 中 replication 条目的来源 IP，限制到明确的同步节点
检查数据目录及 postgres 账号可写路径下是否有来历不明的 .so 文件
自动化脚本里的 psql 调用，避免对不受信服务器使用内联数据行的 COPY FROM STDIN（改用带文件名的 COPY FROM，不受此洞影响）

方案三：权限体系长期治理

REPLICATION 权限的杀伤力这次被彻底暴露——它不只是”读变更流”，而是”触达 OS 层”。把 REPLICATION 当成准超级权限来管理：单独账号、单独审计、定期复核。

入侵排查清单：

– pg_replication_slots 中是否有陌生/异常的逻辑复制槽（特别是 plugin 路径可疑的）

– pg_roles 中 REPLICATION 权限授予记录，比对变更

postgres OS 账号可读目录中的 .so 文件时间戳与来源
psql 使用记录中，是否连接过不受信服务器且使用了 COPY FROM STDIN

⚠️ 安全提醒

PostgreSQL 的季度安全更新向来克制，一次更新塞两个”权限边界被踹开”级别的洞，不多见。6471 尤其值得每个 DBA 立刻放下手里的事：你的 REPLICATION 账号清单，现在就是攻击面清单。

小版本升级兼容性好、停机窗口短，没有理由拖过这个周末。

转发给团队里管数据库的兄弟——尤其是那帮把 REPLICATION 权限随手就发的数据平台同学。

官方参考：

https://www.postgresql.org/support/security/CVE-2026-6464/

https://www.postgresql.org/support/security/CVE-2026-6471/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：撅人《紧急预警 | CVE-2026-6464 / 6471 | PostgreSQL 双洞齐发：一个能让你执行任意代码，一个让你的 psql 反被数据行指挥》