pghoard CVE-2026-63120

Exploitation requires the attacker to already have write access to the backup object storage bucket (S3, GCS, or Azure) used by pghoard, and a database administrator must execute a restore via pghoard_restore get-basebackup using a delta backup manifest that the attacker has poisoned with path-traversal sequences (e.g., ../../../../etc/cron.d/backdoor). Limiting factors: the PR:H storage-write prerequisite and the UI:R requirement that a legitimate restore be triggered mean this is not remotely self-exploitable; only pghoard versions <= 2.7.1 are affected, and the vendor states there are no workarounds - upgrading to 2.7.2 is the only fix.

This is a genuinely high-severity flaw (CVSS 8.4) but with meaningful preconditions that temper real-world urgency. The CVSS vector (AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:H) encodes the key limiters: PR:H means the attacker must already hold write access to the backup object storage (S3/GCS/Azure), and UI:R means a database administrator must actively run a restore. The scope change (S:C) and triple-high impact are justified because a successful attack escapes the pgdata directory to write arbitrary files anywhere on the host (e.g., /etc/cron.d), yielding host code execution. No EPSS score, KEV listing, or SSVC automatable/technical-impact data was supplied, so exploitation probability cannot be quantified from the input. No public exploit was identified at time of analysis - the two references are the vendor GHSA advisory and the 2.7.2 release notes, not working exploit code. The vendor-ecosystem priority label is 'this_week', not act_now/emergency, consistent with a serious post-compromise or insider privilege-escalation primitive rather than a mass-exploitable internet-facing bug. Net: real priority for anyone running pghoard <= 2.7.1 who restores from shared/multi-tenant backup storage, but the PR:H storage-write precondition makes widespread opportunistic exploitation unlikely.

An attacker who has gained write access to the backup object storage (via leaked cloud credentials, a misconfigured bucket, or insider access) plants a delta backup manifest containing path-traversal sequences such as ../../../../etc/cron.d/backdoor. When a DBA later runs pghoard_restore get-basebackup, pghoard writes the attacker-controlled payload outside pgdata onto the host, achieving code execution via the dropped cron job. No public exploit code was identified, though the GHSA advisory describes the technique in detail.