Live › vulnerability › CVE-2026-63120
Go to dashboardpghoard, a PostgreSQL backup daemon, fails to fully block path traversal in backup manifests before version 2.7.2. An attacker who can write to the backup object store can make a database administrator's restore write arbitrary files on the host, such as cron jobs.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Teams that run pghoard to back up PostgreSQL to cloud object storage and that restore from it with pghoard_restore get-basebackup on versions before 2.7.2. Exposure requires that an attacker can write to the backup bucket, so teams that restrict bucket write access to the backup process and do not use pghoard restore are less exposed.
No product ranges from the sources yet.
pghoard_restore --version or pip show pghoard and compare against 2.7.2.2.7.2.2.7.2 or later.pghoard_restore get-basebackup against backups from storage that untrusted parties could write to.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
pghoard is a PostgreSQL backup daemon and restore tooling that stores backup data in cloud object stores. Prior to version 2.7.2, an incomplete path traversal fix in pghoard allows an attacker with write access to the backup object storage (such as S3, GCS, or Azure) to execute arbitrary file writes and directory creation outside the designated PostgreSQL data directory (pgdata). When a database administrator executes a restore operation (via pghoard_restore get-basebackup), a maliciously crafted delta backup manifest with path traversal sequences (e.g., ../../../../etc/cron.d/backdoor) will write arbitrary payloads to the host system. This issue has been patched in version 2.7.2.
This page as .md · .json · in your agent: get_signal("CVE-2026-63120")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.