CVE-2024-10979: PostgreSQL PL/Perl RCE Vulnerability

CVE-2024-10979 Overview

CVE-2024-10979 affects PostgreSQL's PL/Perl procedural language extension. The flaw allows an unprivileged database user to modify sensitive process environment variables, including PATH, within the PostgreSQL server process. Manipulating these variables often enables arbitrary code execution against the database host, even when the attacker has no operating system account on the server. The issue affects PostgreSQL versions prior to 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21. The PostgreSQL Global Development Group released fixes on November 14, 2024. The vulnerability is classified under [CWE-15] (External Control of System or Configuration Setting) and [CWE-610] (Externally Controlled Reference to a Resource in Another Sphere).

Critical Impact
Authenticated database users with access to PL/Perl can alter environment variables to hijack subprocess execution and run arbitrary code on the PostgreSQL host.

Affected Products

PostgreSQL versions prior to 17.1
PostgreSQL versions prior to 16.5, 15.9, and 14.14
PostgreSQL versions prior to 13.17 and 12.21

Discovery Timeline

2024-11-14 - CVE-2024-10979 published to NVD
2024-11-14 - PostgreSQL Global Development Group released patched versions 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21
2025-11-03 - Last updated in NVD database

Technical Details for CVE-2024-10979

Vulnerability Analysis

PostgreSQL's PL/Perl extension embeds the Perl interpreter inside the database backend process. Perl exposes the %ENV hash, which lets scripts read and write the process environment. The PostgreSQL implementation failed to restrict writes to environment variables from PL/Perl code, allowing any user who can execute PL/Perl functions to alter the backend's runtime environment.

Because PostgreSQL backend processes inherit the operating system identity of the PostgreSQL service account, environment changes persist for any subprocess the backend later spawns. Variables such as PATH, PERL5LIB, LD_PRELOAD, and LD_LIBRARY_PATH directly influence how external binaries and shared libraries are located and loaded. The combination produces a reliable path from authenticated SQL access to operating system code execution.

Root Cause

The root cause is missing isolation between Perl's mutable %ENV hash and the host process environment. PL/Perl did not intercept assignments to %ENV or tie the hash to a sandboxed copy. Trusted PL/Perl (plperl) was intended to be safe for unprivileged users, so this gap broke the documented security boundary between SQL-level privileges and operating system-level control.

Attack Vector

An attacker requires only an authenticated PostgreSQL account with permission to execute a PL/Perl function. The attacker writes a PL/Perl routine that assigns attacker-controlled values to entries in %ENV, such as redirecting PATH to a directory containing a malicious binary. When PostgreSQL subsequently invokes an external program, for example through an archive command, COPY PROGRAM, or extension hook, the attacker-controlled binary executes under the PostgreSQL service account. Refer to the PostgreSQL CVE-2024-10979 Advisory and the GitHub PostgreSQL Vulnerability Info for technical specifics.

Detection Methods for CVE-2024-10979

Indicators of Compromise

PL/Perl function definitions that assign values to $ENV{...} keys, particularly PATH, LD_PRELOAD, LD_LIBRARY_PATH, or PERL5LIB.
Unexpected child processes spawned by postgres backend processes, especially shells or interpreters launched from non-standard directories.
New or modified files in directories writable by the PostgreSQL service account that match locations referenced by PATH.
PostgreSQL server logs showing repeated CREATE FUNCTION ... LANGUAGE plperl events from unprivileged roles.

Detection Strategies

Audit pg_proc for functions written in plperl or plperlu and review their source for %ENV writes.
Enable log_statement = 'ddl' to capture function creation by non-administrative roles.
Correlate database query telemetry with endpoint process telemetry to flag postgres-spawned executables outside expected binary paths.

Monitoring Recommendations

Forward PostgreSQL audit logs and host process telemetry to a centralized analytics platform for cross-source correlation.
Alert on PL/Perl function creation by roles that do not normally author stored procedures.
Track outbound network connections initiated by postgres backends to detect post-exploitation activity.

How to Mitigate CVE-2024-10979

Immediate Actions Required

Upgrade PostgreSQL to 17.1, 16.5, 15.9, 14.14, 13.17, or 12.21 or later as appropriate for the deployed major version.
Inventory all databases that have the plperl or plperlu extension installed and review existing PL/Perl functions for malicious environment writes.
Restrict the pg_proc catalog and revoke CREATE privileges on schemas from roles that do not require them.
Rotate credentials and review host audit logs if PL/Perl was exposed to untrusted users before patching.

Patch Information

The PostgreSQL Global Development Group released fixed builds on November 14, 2024. Apply versions 17.1, 16.5, 15.9, 14.14, 13.17, or 12.21 from the official distribution channels. Downstream packages from the Debian LTS Announcement and the NetApp Security Advisory ntap-20250110-0003 include the corresponding fixes for their respective platforms.

Workarounds

Drop the plperl extension from databases that do not require it using DROP EXTENSION plperl CASCADE.
Revoke USAGE on the plperl language from PUBLIC and grant it only to vetted roles.
Run PostgreSQL under a dedicated service account with a minimal PATH and no write access to directories referenced in that PATH.

bash

# Configuration example
# Inspect installed procedural languages
psql -c "SELECT lanname FROM pg_language WHERE lanname LIKE 'plperl%';"

# Remove PL/Perl if it is not required
psql -c "DROP EXTENSION IF EXISTS plperl CASCADE;"

# Restrict language usage to trusted roles only
psql -c "REVOKE USAGE ON LANGUAGE plperl FROM PUBLIC;"