CVE-2024-1713

What it actually does

A database user able to create objects can arrange for deferred triggers to execute with superuser privileges during autovacuum when plv8 is present.

Why it matters to the business

Attackers with limited database access can obtain elevated privileges, increasing the chance of data exposure or unauthorized changes in environments where the vulnerable component is deployed.

How an attack unfolds

An attacker creates a database object that registers a deferred trigger, then waits for or triggers autovacuum to cause the trigger to run as superuser, completing the privilege escalation.

How to fix it

Upgrade affected installations to the fixed versions provided by the vendor. For xinetd on AlmaLinux 8, update to 2:2.3.15-24.el8 or later equivalent packages that address the trigger execution issue.

How to confirm the fix worked

Verify package versions match or exceed the fixed releases, review database extension configurations for plv8, and confirm autovacuum trigger behavior no longer permits superuser execution from unprivileged objects.

Typical attack path

1. Obtain ability to create objects in the target database
2. Install or ensure plv8 extension is active
3. Define a deferred trigger that performs privileged actions
4. Allow or force autovacuum to execute the trigger
5. Execute actions with superuser context

How to detect it

Review database logs for unexpected trigger executions during autovacuum, inspect object creation events by non-superusers, and look for privilege changes or actions performed outside normal maintenance windows.

What your security team should do

• Apply vendor updates to reach the fixed package versions immediately
• Restrict object creation privileges to the minimum necessary users
• Monitor for unusual autovacuum activity or trigger definitions
• Audit database extensions and remove plv8 if not required