CVE-2026-6475

What it actually does

CVE-2026-6475 is a symlink-following flaw in PostgreSQL tooling, specifically pg_basebackup when using plain format and pg_rewind. A malicious or compromised origin PostgreSQL superuser can cause these tools to follow symbolic links while writing backup or rewind output, allowing overwrite of local files on the system running the command. The impact can include modification of files owned or writable by the PostgreSQL operating-system account, such as shell startup files, service-related files, or database-adjacent configuration artifacts. Successful exploitation can lead to local file overwrite, integrity compromise, and potential hijacking of the PostgreSQL OS account when an administrator later performs relevant actions before starting PostgreSQL, such as moving the copied files to another VM, snapshotting the VM, or otherwise relying on the produced filesystem state.

Why it matters to the business

Organizations using PostgreSQL backup, cloning, migration, disaster-recovery, or rewind workflows could unintentionally import attacker-controlled filesystem changes from an untrusted or compromised source server. In practical terms, this can turn a backup, replica rebuild, or recovery operation into a path for compromising the destination host or the PostgreSQL service account. Because exploitation requires control of the origin PostgreSQL superuser and user interaction through running pg_basebackup or pg_rewind, the risk is highest for environments that restore from third-party, shared, compromised, or insufficiently trusted PostgreSQL origins. The CVSS score is high, but EPSS is currently low and there is no CISA KEV listing or known ransomware association, so priority should be driven by exposure of backup/rewind workflows and trust boundaries rather than broad internet exploitation pressure.

How an attack unfolds

An attacker first obtains PostgreSQL superuser-level control on the origin server used for pg_basebackup or pg_rewind. From that position, the attacker crafts files and symbolic links in the data directory or relevant filesystem content that will be processed by the PostgreSQL tooling. An administrator or automation on another host then runs pg_basebackup in plain format or pg_rewind against that origin. During output generation, vulnerable versions may follow attacker-controlled symlinks and overwrite local destination files, such as files in the PostgreSQL OS account home directory. The attacker’s payload takes effect only when the overwritten file is later used, for example when a shell startup file is executed, a moved/snapshotted VM is booted, or other operational steps occur before PostgreSQL is started. PostgreSQL startup itself already implies trust in the origin superuser through mechanisms such as shared_preload_libraries, so the distinct risk is compromise during the interim handling of backup or rewind output.

How to fix it

Upgrade PostgreSQL client/server tooling to fixed releases: PostgreSQL 18.4 or later, 17.10 or later, 16.14 or later, 15.18 or later, or 14.23 or later, depending on the major version in use. Ensure the upgraded binaries used by automation are the actual pg_basebackup and pg_rewind binaries on PATH, because backup hosts, replica builders, containers, and administrative jump hosts may carry separate PostgreSQL client packages from the database server. Avoid running pg_basebackup in plain format or pg_rewind against origins that are not fully trusted. Treat PostgreSQL superuser access on the origin as equivalent to trust over the recovery artifact. Where upgrade cannot be completed immediately, prefer backup formats and workflows not affected by the plain-format symlink behavior, isolate backup/rewind output into disposable directories or containers, do not place output directly over sensitive filesystem locations, and inspect generated trees for symbolic links before moving, snapshotting, or booting systems from them. Restrict who can initiate base backup and rewind operations, limit origin superuser access, and protect backup automation credentials.

How to confirm the fix worked

Confirm the PostgreSQL version used by all relevant systems and automation by running `postgres --version`, `pg_basebackup --version`, and `pg_rewind --version` from the same execution context used by backup and recovery jobs. Validate that versions are at or above 18.4, 17.10, 16.14, 15.18, or 14.23 for the deployed major branch. Review package inventories, container images, backup appliances, CI/CD images, and administrative hosts for older PostgreSQL client tools. Test backup and rewind workflows in a non-production environment to verify that symlink entries in source content do not result in writes outside the intended destination directory. Inspect recent backup or rewind output directories with commands such as `find <backup_output> -type l -ls` and verify that no unexpected symbolic links or overwritten local files exist. Confirm automation writes to clean, dedicated directories and does not reuse directories containing sensitive files.

Typical attack path

1. Compromise or otherwise obtain PostgreSQL superuser privileges on an origin PostgreSQL server.
2. Create attacker-controlled symbolic links or filesystem entries in content that vulnerable pg_basebackup plain-format or pg_rewind operations will process.
3. Wait for an administrator, migration process, backup job, replica rebuild, or recovery automation to run pg_basebackup or pg_rewind from a vulnerable PostgreSQL version against the origin.
4. Cause the destination tooling to follow the symbolic link and overwrite a local file writable in the execution context, such as a PostgreSQL OS account startup or configuration file.
5. Rely on a later operational action, such as moving the files to another VM, creating a snapshot, opening a shell, or otherwise using the overwritten file before PostgreSQL startup, to execute or activate the attacker-controlled content.
6. Use the resulting control of the PostgreSQL operating-system account or modified local files to persist, escalate operational impact, or tamper with database recovery workflows.

How to detect it

Look for evidence that vulnerable pg_basebackup or pg_rewind commands were run against an untrusted or later-compromised origin, followed by unexpected file modifications on the destination host. Useful log sources include shell history, sudo logs, auditd or equivalent file integrity logs, EDR process telemetry, PostgreSQL administrative logs, backup orchestration logs, systemd journal entries, package inventory data, and filesystem metadata from backup staging directories. Hunt for executions of `pg_basebackup` using plain format options or `pg_rewind`, especially where the working directory or destination directory was later moved, snapshotted, or reused. Correlate those executions with writes to PostgreSQL OS account home files, shell initialization files, service override files, cron locations, SSH authorized keys, shared library paths, or other persistence-sensitive paths. Inspect backup/rewind output trees for symbolic links and compare against expected PostgreSQL data directory contents. Review origin PostgreSQL activity for suspicious superuser actions prior to the backup or rewind, including creation or modification of unusual files, extension/library loading configuration, or unexpected administrative role use. If EDR or audit telemetry is available, search for file-write events by `pg_basebackup` or `pg_rewind` that target paths outside the intended backup destination.

• process_name=pg_basebackup
• process_name=pg_rewind
• pg_basebackup -Fp
• pg_basebackup --format=plain
• pg_basebackup --format p
• pg_rewind --target-pgdata
• /var/lib/postgres/.bashrc
• /var/lib/postgresql/.bashrc
• /var/lib/pgsql/.bashrc
• /var/lib/postgres/.profile
• /var/lib/postgresql/.profile
• /var/lib/pgsql/.profile
• /var/lib/postgres/.ssh/authorized_keys
• /var/lib/postgresql/.ssh/authorized_keys
• /var/lib/pgsql/.ssh/authorized_keys
• find . -type l
• shared_preload_libraries

What your security team should do

• Prioritize patching PostgreSQL tooling on systems that run pg_basebackup or pg_rewind, especially backup servers, replica builders, migration hosts, recovery automation, containers, and administrator workstations.
• Inventory all PostgreSQL major versions in use and map them to the fixed releases: 18.4+, 17.10+, 16.14+, 15.18+, and 14.23+.
• Identify workflows that run pg_basebackup in plain format or pg_rewind against origins outside a strict trust boundary, and suspend or isolate those workflows until upgraded.
• Treat compromise of an origin PostgreSQL superuser as a potential compromise of downstream backup and recovery artifacts produced from that origin.
• Review recent backup, clone, migration, and rewind operations performed since publication for unexpected symbolic links, overwritten files, or unusual changes to PostgreSQL OS account files.
• Harden backup automation by using dedicated low-privilege operating-system accounts, clean destination directories, disposable staging environments, and post-run validation before moving or snapshotting generated files.
• Restrict and monitor PostgreSQL superuser assignment and credentials, because origin superuser control is a prerequisite for meaningful exploitation.
• Add detection logic for pg_basebackup and pg_rewind executions followed by unexpected writes to shell startup files, service files, or files outside approved backup directories.
• Because current EPSS is low, there is no KEV listing, and exploit maturity is reported as none, prioritize remediation based on operational exposure rather than emergency internet-facing patch queues.