22年PostgreSQL漏洞演变为远程代码执行风险

如果你在2026年4月告诉我，有一个问题——“Mehmet，我们可以在这个项目中使用托管 PostgreSQL 吗？”会让我陷入人生中最深的兔子洞，我会笑出声来。

几个月后，我终于找到了那个兔子洞的底部。那是一个存在于 PostgreSQL 核心中的 22 年零日漏洞。

在这篇博文中，你将读到我是如何最终发现 PostgreSQL 中一类新型类型混淆漏洞的故事。

这是名为“托管 PostgreSQL 行业的系统性风险”的博客文章系列的第三部分。对于那些错过了前两部分的读者，请随意从第 1 部分和第 2 部分开始，这将为你提供关于这场疯狂的完整背景。

TLDR：

我在一个复合类型中给 PostgreSQL 赋了一个值，然后修改了其中一个字段的类型，并要求它读回该值。这种类型混淆导致了我所见过的最可靠的内存破坏利用之一。但我并不是从寻找 PostgreSQL 核心漏洞开始的。

我正在利用 pg_clickhouse，而要让那个利用起作用，留给我一个关于 PostgreSQL 如何理解其自身数据的问题。在我的 AI 代理作为老师的指导下，我一步步地研究了内部机制。然后，一个看似无关的对话给了我将这一切联系起来的灵感，最终我发现自己盯着一个已经存在了一段时间的原语。

这是这些部分如何组合在一起的完整真实故事，我相信你会喜欢这个故事。

2026 年 8 月初

在 6 月和 7 月期间，我一直在利用多个 PostgreSQL 扩展中的内存破坏漏洞。我实现代码执行的扩展之一是 pg_clickhouse。那个案例研究有自己的故事，我会在未来分享。

重要的是，那个利用迫使了我去学习什么。pg_clickhouse 将 ClickHouse 值转换为原生 PostgreSQL 值。ClickHouse 数组不是 PostgreSQL 数组，对吧？所以该扩展必须按照 PostgreSQL 期望的格式将其元素重建为 Datum 值。那个转换中的错误最终给了我代码执行的机会。

这是我第一次在 PostgreSQL 的世界里接触到 Datum、OID 等事物。我学到的知识仅足以完成利用，但一个问题仍留在我的脑海深处：

大约在 7 月下旬，我终于从扩展中抽身出来，只是带着那个问题深入到了 PostgreSQL 核心中。

免责声明：我已经向供应商报告了 pg_clickhouse 的越界写入 + 读取链漏洞，他们已于 6 月 23 日修复。

PostgreSQL 类型 101

我开始通过一个非常简单的查询来学习。当我运行最简单的查询 SELECT 1337 时会发生什么？

虽然我避开了 PostgreSQL 内部机制中的所有黑魔法，但我坚持对数据类型基础知识进行突击学习。

我从这个查询开始。