CVE-2024-7348 is a time-of-check to time-of-use race in pg_dump, the backup tool shipped with PostgreSQL. It is rated High (CVSS 8.8). An object creator can run arbitrary SQL functions as the user running pg_dump, often a superuser. PostgreSQL fixed it in 16.4, 15.8, 14.13, 13.16 and 12.20.
What's affected
The PostgreSQL project advisory says all versions before the following releases are affected, one fixed release per supported branch:
| Branch | Fixed in |
|---|---|
| 16 | 16.4 |
| 15 | 15.8 |
| 14 | 14.13 |
| 13 | 13.16 |
| 12 | 12.20 |
The advisory dates the fix to 8 August 2024. The affected component is the core server tooling, specifically pg_dump. The NVD record scores it 8.8 with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, and the PostgreSQL page lists the same score, though it labels the vector as CVSS 3.0. Both sources agree on High.
Because the flaw sits in a client tool, what matters is the version of pg_dump on the machine that runs your backups, not only the version of the database server. A backup host with an old client package can lag behind the server it dumps.
How to check if you're exposed
Check the server and the client separately.
psql -c "SELECT version();"
pg_dump --version
If either reports a release below the fixed number for its branch, plan an upgrade. On Debian or Ubuntu, apt list --installed 2>/dev/null | grep postgresql-client shows the client packages. On RHEL family hosts, use rpm -qa | grep postgresql. Also look at container images that bundle pg_dump for scheduled backups, since those are easy to forget.
Then ask a second question: who can create tables, views or foreign tables in the databases you dump? The advisory describes the attacker as an object creator, so the risk depends on that privilege.
What to do now
- Upgrade PostgreSQL and its client tools to 16.4, 15.8, 14.13, 13.16, 12.20 or later on your branch.
- Update every host and image that runs pg_dump, including backup jobs, CI runners and admin laptops.
- Review which roles hold CREATE rights on schemas in shared databases, and remove them where they are not needed.
- Avoid running pg_dump as a superuser against databases where untrusted users can create objects, until the upgrade is done.
- Run a dependency and image scan so you can see every place a vulnerable client ships. The free in-browser scanner at gold.safeguard.sh/scan is a quick start.
The advisory does not describe any workaround other than upgrading, so treat the steps above on privileges as risk reduction, not a fix.
Why it matters
The weakness is CWE-367, a time-of-check to time-of-use race. A privileged tool looks at the state of the database, then acts on it a moment later. If someone else can change that state in between, the tool acts on something different from what it checked. Here, replacing another relation type with a view or foreign table lets the creator's functions run with the dumping user's rights.
The advisory notes that winning the race is trivial when the attacker holds an open transaction. That removes the usual comfort that races are hard to hit. The practical lesson is that backup tools often run with the highest privilege in the environment, so their bugs deserve the same urgency as server bugs. The record does not mark this CVE as exploited in the wild, and it is not in the CISA KEV catalog.
Quick check
Do I need to upgrade the server if only pg_dump is old?
The flaw is in pg_dump, so the client tool is what runs the vulnerable code. Update the client packages on every host that runs backups, and upgrade the server to a fixed release on its branch as well.
Is this exploited in the wild?
The record's KEV flag is false, and the PostgreSQL advisory does not report exploitation.
Sources
Last reviewed: 19 October 2026.
