Missing authorization in PostgreSQL logical decoding

CVE-2026-6471, nicknamed PostGREShell, is a missing-authorization flaw in PostgreSQL's logical decoding subsystem that has existed since 2014. Any database user holding the REPLICATION privilege — commonly granted to backup tools (pgBackRest, Barman), CDC pipelines (Debezium), monitoring agents, and read-replica configurations — can specify an arbitrary shared library as a logical decoding output plugin. PostgreSQL's server process calls dlopen() on that path without verifying it is a legitimate plugin, executing the library's init code as the postgres OS user. The result is full remote code execution on the database host. Affected versions span all supported branches: PostgreSQL 14.x < 14.24, 15.x < 15.19, 16.x < 16.15, 17.x < 17.11, and 18.x < 18.6.

The vendor rates this HIGH / 7.2 with PR:H (high privileges required), and that score is directionally correct — the REPLICATION privilege is a real gate. However, in enterprise deployments, REPLICATION credentials proliferate across service accounts for backups, streaming replicas, and event-driven architectures. Those credentials are the softest target in most PostgreSQL estates. When you factor in that PostgreSQL almost always sits on a production data tier — hosting PII, financial records, or regulated data — the blast radius of a single successful exploit is severe: full data exfiltration plus persistent backdoor. The vendor's 7.2 is fair but slightly conservative for organizations running PostgreSQL as their primary OLTP engine.

Why this verdict

• PR:H is real but soft friction. The REPLICATION privilege is a genuine gate — not every database user has it. However, in practice, backup tools (pgBackRest, Barman), CDC pipelines (Debezium, Kafka Connect), and streaming replicas all require REPLICATION-privileged service accounts. These credentials are the most commonly shared and least frequently rotated secrets in a PostgreSQL estate.
• Role multiplier: production database engine. PostgreSQL is explicitly a high-value-role component. The majority of PostgreSQL installations serve production workloads holding PII, financial, or regulated data. RCE on the database host = mass data egress from that cluster. This floors the verdict at HIGH regardless of friction.
• 12-year attack surface amplifies exposure. Every supported PostgreSQL branch back to 14.x (and unsupported branches back to 9.4) is vulnerable. Organizations running any unpatched version since 2014 are affected, making the population enormous.
• No public PoC tempers urgency — but barely. The absence of a GitHub PoC and low EPSS (0.00285) reduce the immediacy of mass exploitation. However, the technique is conceptually simple (call pg_create_logical_replication_slot with a crafted library path), and skilled adversaries do not need a public PoC.

Why not higher?

A CRITICAL rating would require either active KEV listing, a public weaponized exploit enabling mass automated exploitation, or unauthenticated access. This CVE requires high privileges (REPLICATION), the target database must have wal_level = logical configured, and the attacker needs a way to stage a malicious .so on the host filesystem. Cloud-managed PostgreSQL (RDS, Cloud SQL, Azure Database for PostgreSQL) is not exploitable because users have no OS filesystem access, which eliminates a large fraction of the global PostgreSQL population from the vulnerable pool.

Why not lower?

Downgrading to MEDIUM would ignore that PostgreSQL is a canonical production data-tier component where successful exploitation yields OS-level RCE and full cluster data access. The REPLICATION privilege, while PR:H, is routinely granted to multiple service accounts per cluster. The 12-year vulnerability window means virtually every on-premises PostgreSQL installation is affected. Exploitation attempts have already been detected in the wild.

1. Audit and restrict REPLICATION privilege grants immediately — Run SELECT rolname FROM pg_roles WHERE rolreplication = true; on every cluster. Revoke REPLICATION from any role that does not strictly require it. This directly eliminates the attack prerequisite. Deploy within 30 days per the noisgate mitigation SLA for HIGH.
2. Set output_plugin_libraries on patched versions — The patch introduces a new GUC output_plugin_libraries that whitelists permitted logical decoding plugins. After upgrading, configure this parameter to restrict dlopen targets to only your approved plugins (e.g., pgoutput, wal2json). This is defense-in-depth even after patching.
3. Restrict replication connections in pg_hba.conf — Ensure pg_hba.conf replication entries use hostssl (not host), restrict source CIDR to specific replica/backup IPs only, and require certificate-based authentication instead of password. This limits who can even attempt the exploit.
4. Enable SELinux/AppArmor confinement for postgres — Configure mandatory access control policies to prevent the postgres process from calling dlopen() on files outside /usr/lib/postgresql/*/lib/. This blocks step 2 of the attack path even if the attacker has REPLICATION credentials.
5. Enable replication command logging — Set log_replication_commands = on and forward logs to SIEM. Alert on CREATE_REPLICATION_SLOT commands with non-standard plugin names. This provides high-fidelity detection of exploitation attempts.

Run this script on each PostgreSQL host as any user who can connect to the database (e.g., postgres). Invoke with: bash check_cve_2026_6471.sh. Requires psql in PATH and the ability to connect to the local PostgreSQL instance (peer auth or password via .pgpass/PGPASSWORD).

#!/usr/bin/env bash
# check_cve_2026_6471.sh — Detect CVE-2026-6471 (PostGREShell)
# Checks PostgreSQL server version against patched releases.
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

VERSION=$(psql -tAc "SHOW server_version;" 2>/dev/null || echo "")

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not connect to PostgreSQL"
  exit 2
fi

MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)

echo "Detected PostgreSQL version: $VERSION"

# Check against fixed versions: 14.24, 15.19, 16.15, 17.11, 18.6
case "$MAJOR" in
  14) FIXED_MINOR=24 ;;
  15) FIXED_MINOR=19 ;;
  16) FIXED_MINOR=15 ;;
  17) FIXED_MINOR=11 ;;
  18) FIXED_MINOR=6  ;;
  19) echo "PATCHED — PostgreSQL $VERSION (19.x includes the fix)"; exit 0 ;;
  *)  
    if [ "$MAJOR" -lt 14 ]; then
      echo "VULNERABLE — PostgreSQL $VERSION is end-of-life and affected"
      exit 1
    fi
    echo "UNKNOWN — unrecognized major version $MAJOR"
    exit 2
    ;;
esac

if [ "$MINOR" -ge "$FIXED_MINOR" ]; then
  echo "PATCHED — PostgreSQL $VERSION (fixed in $MAJOR.$FIXED_MINOR)"
  exit 0
else
  echo "VULNERABLE — PostgreSQL $VERSION (update to $MAJOR.$FIXED_MINOR+)"
  # Bonus: check for replication users as risk indicator
  REPL_USERS=$(psql -tAc "SELECT count(*) FROM pg_roles WHERE rolreplication = true;" 2>/dev/null || echo "?")
  echo "  Replication-privileged roles on this cluster: $REPL_USERS"
  WAL_LEVEL=$(psql -tAc "SHOW wal_level;" 2>/dev/null || echo "?")
  echo "  wal_level: $WAL_LEVEL (logical = exploitable, replica/minimal = reduced risk)"
  exit 1
fi

Sources

1. PostgreSQL Official Advisory — CVE-2026-6471
2. PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 Release Announcement
3. SecurityAffairs — PostGREShell 12-Year-Old PostgreSQL Vulnerability
4. SUSE Security — CVE-2026-6471
5. TheHackerWire — CVE-2026-6471 High Vulnerability
6. News4Hackers — Critical PostgreSQL Vulnerability Exploited
7. DevGuard — ALPINE-CVE-2026-6471