<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>PostgreSQL on HackingPassion.com : root@HackingPassion.com-[~]</title><link>https://hackingpassion.com/tags/postgresql/</link><description>Recent content in PostgreSQL on HackingPassion.com : root@HackingPassion.com-[~]</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 07 Sep 2026 13:45:15 +0200</lastBuildDate><atom:link href="https://hackingpassion.com/tags/postgresql/index.xml" rel="self" type="application/rss+xml"/><item><title>PostgreSQL Logical Decoding Flaw Let a Replication Account Take Over the Server for 12 Years</title><link>https://hackingpassion.com/postgresql-logical-decoding-replication-takeover/</link><pubDate>Mon, 07 Sep 2026 13:45:15 +0200</pubDate><guid>https://hackingpassion.com/postgresql-logical-decoding-replication-takeover/</guid><description>&lt;p>&lt;strong>A database account that was only allowed to copy data could run commands on the server itself. The admins never gave it that right. The hole has been open since PostgreSQL 9.4 shipped in 2014, twelve years.&lt;/strong>&lt;/p>
&lt;p>That account has one job. It has no rights on your tables and it cannot create or drop anything. It gets permission to follow along with what changes in the database, because a backup tool or a standby server has to know what happened. In PostgreSQL that permission is called &lt;code>REPLICATION&lt;/code>.&lt;/p></description></item></channel></rss>