{"id":23831,"date":"2026-09-09T05:57:31","date_gmt":"2026-09-09T05:57:31","guid":{"rendered":"https:\/\/scannn.com\/the-database-powering-much-of-the-internet-had-an-open-door-for-12-years\/"},"modified":"2026-09-09T05:57:31","modified_gmt":"2026-09-09T05:57:31","slug":"the-database-powering-much-of-the-internet-had-an-open-door-for-12-years","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/the-database-powering-much-of-the-internet-had-an-open-door-for-12-years\/","title":{"rendered":"The database powering much of the internet had an open door for 12 years"},"content":{"rendered":"\n
\n

Imagine you’ve built a fortress. Guards at the front gate, scanners at every door, a guest list checked twice. You hired the best architects, ran the audits, passed the compliance reviews. By every measure, the place is locked down.<\/p>\n

But you missed something. Around the back, there’s a small, unmarked entrance used by the cleaning crew. It’s been there for years, and nobody thought to put a guard on it.<\/p>\n

Then one day, someone figures out that if you walk in through that entrance wearing a cleaning uniform, the entire fortress opens up: the armory, the vault, the control room. Once you’re inside, everyone assumes you belong.<\/p>\n

That’s PostGREShell. The “fortress” is PostgreSQL, the database quietly powering much of the internet. The “cleaning crew entrance” is the replication protocol, used by backup accounts present in every PostgreSQL setup. The vulnerability we discovered means anyone with access to that entrance can bypass every security system PostgreSQL has built, load arbitrary code onto the server, escalate to full superuser, and install a backdoor that survives cleanup.<\/p>\n

It’s been sitting there, unguarded, since 2014.<\/p>\n

TL;DR<\/h2>\n

Cyera Research discovered a critical vulnerability (CVE-2026-6471<\/a>) in PostgreSQL, the world’s #1 open-source database that\u2019s used by 39,000+ companies including Netflix, Instagram, Spotify, and Uber.<\/p>\n

The flaw lets a low-privilege “backup” account load and execute arbitrary code on the database server, achieving remote code execution across Windows, Linux, and macOS. That foothold escalates to full PostgreSQL superuser with persistent backdoor access, turning a routine replication account into total database and server compromise.<\/p>\n

The vulnerability has existed in every PostgreSQL version since 2014 (9.4+) and was never patched until now. A threat hunt across VirusTotal turned up 114 malicious PostgreSQL plugins already in the wild, including trojans, cryptocurrency miners, and reverse shells.<\/p>\n

Why the blast radius is enormous<\/h2>\n

Every time you stream Netflix, scroll Instagram, book an Uber, or open Spotify, a database is handling millions of transactions behind the scenes. For a huge share of the internet, that database is PostgreSQL. It\u2019s the world’s most popular open-source database, fourth-most popular<\/a> overall, and the top choice among professional developers. It’s the engine behind AWS RDS, Azure Database, Google Cloud SQL, Supabase, and Neon, and it’s used in production by 39,000+ verified companies.<\/p>\n

PostgreSQL isn’t just storing cat photos and shopping carts. It runs financial transactions, medical records, government infrastructure, SaaS platforms, and AI\/ML pipelines. That means a critical vulnerability brings a huge blast radius.<\/p>\n

The vulnerability: one door has a guard, the other doesn’t<\/h2>\n

Why databases have “backup accounts”\u00a0<\/h3>\n

In production you rarely run one copy of a database. You run a primary that handles writes and one or more replicas kept in sync for backups, disaster recovery, and read scaling. PostgreSQL syncs them over a dedicated replication protocol, and to use it you need an account with the REPLICATION attribute. These accounts are everywhere. Every backup tool, standby server, CDC pipeline, and monitoring system that reads the write-ahead log uses one. They’re treated as low-risk operational plumbing \u2014 PostgreSQL’s own docs describe the attribute as needed to “initiate streaming replication,” not to run code.<\/p>\n

\n
<\/div>\n<\/figure>\n

The output plugin<\/h3>\n

Logical replication (wal_level = logical<\/code>) records changes as table events external tools can read. This is the basis for Change Data Capture, Debezium, cloud migrations, and real-time analytics. A client reads those changes by creating a logical replication slot<\/em>, and each slot names an output plugin<\/em> (like pgoutput<\/code> or wal2json<\/code>) that PostgreSQL loads to format the stream.<\/p>\n

Here’s the problem: that plugin name goes straight to the loader.<\/p>\n

PostgreSQL plugins are compiled code files (.so<\/code>, .dll<\/code>, .dylib<\/code>) loaded into the database’s own process. When one loads, PostgreSQL runs its _PG_init()<\/code> function immediately, with the full privileges of the server process (similar to a phone app, but one that runs as root with no permission prompt). PostgreSQL knows this is dangerous, so it built a security mechanism called check_restricted_library_name()<\/code> that forces non-superusers to load plugins only from one safe, admin-controlled directory, with no path traversal or absolute paths.<\/p>\n

Let’s look at what happens when PostgreSQL loads that plugin<\/p>\n

static void
\nLoadOutputPlugin(OutputPluginCallbacks *callbacks, const char *plugin)
\n{
\n LogicalOutputPluginInit plugin_init;
\n plugin_init = (LogicalOutputPluginInit)
\n load_external_function(plugin, “_PG_output_plugin_init”, false, NULL);<\/p>\n

That mechanism works. It’s just never called on the replication path.\u00a0<\/p>\n

When PostgreSQL loads the output plugin, the name from the user’s CREATE_REPLICATION_SLOT<\/code> command is passed directly to the loader. No validation, no sanitization, no restriction check. The SQL LOAD<\/code> command, by contrast, passes a !superuser()<\/code> flag that triggers the path validation. The replication path passes nothing. And the replication protocol’s parser accepts almost any character inside a double-quoted plugin name: slashes, backslashes, dots, ..\/ traversal, even Windows UNC paths. So an attacker can hand the loader a full filesystem path, and it reaches dlopen() <\/code>(Linux\/macOS) or LoadLibrary()<\/code> (Windows) exactly as typed.<\/p>\n

\n
\"\"<\/div>\n<\/figure>\n

The whole bug is code execution via dlopen()<\/code>. The fix is two lines of C:<\/p>\n