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

CVE-2024-10979 Overview

CVE-2024-10979 is a critical environment variable control vulnerability in PostgreSQL's PL/Perl procedural language extension. The flaw allows an unprivileged database user to manipulate sensitive process environment variables, such as PATH, which can lead to arbitrary code execution on the underlying server—even without direct operating system access.

Critical Impact

Unprivileged database users can achieve arbitrary code execution on PostgreSQL servers by manipulating environment variables through PL/Perl, potentially leading to complete system compromise.

Affected Products

• PostgreSQL versions before 17.1
• PostgreSQL versions before 16.5
• PostgreSQL versions before 15.9
• PostgreSQL versions before 14.14
• PostgreSQL versions before 13.17
• PostgreSQL versions before 12.21

Discovery Timeline

• November 14, 2024 - CVE-2024-10979 published to NVD
• November 3, 2025 - Last updated in NVD database

Technical Details for CVE-2024-10979

Vulnerability Analysis

This vulnerability stems from improper control of environment variables (CWE-15) and externally controlled reference to a resource in another sphere (CWE-610) within PostgreSQL's PL/Perl implementation. The PL/Perl extension allows database users to write stored procedures and functions using the Perl programming language. However, the implementation fails to properly restrict modifications to sensitive environment variables from within PL/Perl code.

When a database user with privileges to execute PL/Perl functions manipulates environment variables like PATH, they can redirect system command execution to malicious binaries. This is particularly dangerous because the code executes in the context of the PostgreSQL server process, which typically runs with elevated privileges on the host system.

Root Cause

The root cause lies in PostgreSQL's PL/Perl extension not implementing adequate safeguards against environment variable manipulation. PL/Perl functions execute within the PostgreSQL backend process, and the extension provides access to Perl's %ENV hash, which directly maps to the process environment. Without proper restrictions, any user with CREATE FUNCTION privileges on PL/Perl can modify critical environment variables that affect how external commands are resolved and executed.

This architectural oversight allows a privilege escalation path from database-level access to operating system-level code execution, bypassing the traditional security boundary between database operations and host system access.

Attack Vector

The attack vector is network-based, requiring only low-privileged authenticated access to the PostgreSQL database. An attacker needs the ability to create and execute PL/Perl functions. The exploitation path typically involves:

1. Creating a PL/Perl function that modifies the PATH environment variable
2. Pointing the modified PATH to a directory containing malicious executables
3. Triggering the execution of system commands that will now resolve to the attacker-controlled binaries

The vulnerability does not require user interaction and can be exploited remotely through standard database connections. The attack complexity is low, as the manipulation of environment variables through PL/Perl is straightforward for anyone with basic Perl knowledge.

For detailed technical analysis, refer to the PostgreSQL Security Advisory and the GitHub Vulnerability Documentation.

Detection Methods for CVE-2024-10979

Indicators of Compromise

• Unusual PL/Perl functions that reference or modify %ENV hash values
• Database audit logs showing creation of PL/Perl functions with environment variable manipulation
• Unexpected process executions originating from the PostgreSQL server process
• Modified environment variables in PostgreSQL backend processes, particularly PATH, LD_PRELOAD, or LD_LIBRARY_PATH

Detection Strategies

• Monitor PostgreSQL audit logs for CREATE FUNCTION statements using PL/Perl language with references to %ENV
• Implement database activity monitoring to detect unusual function creation patterns by non-administrative users
• Deploy endpoint detection to identify anomalous child processes spawned by PostgreSQL backends
• Review existing PL/Perl functions across all databases for environment variable manipulation code

Monitoring Recommendations

• Enable PostgreSQL logging with log_statement = 'ddl' to capture all function creation events
• Configure SentinelOne to monitor PostgreSQL process trees for unexpected child process execution
• Set up alerts for modification of security-sensitive environment variables in database server processes
• Regularly audit PL/Perl function definitions using pg_proc system catalog queries

How to Mitigate CVE-2024-10979

Immediate Actions Required

• Upgrade PostgreSQL to patched versions: 17.1, 16.5, 15.9, 14.14, 13.17, or 12.21
• Restrict CREATE FUNCTION privileges for PL/Perl to trusted administrators only
• Audit existing PL/Perl functions for environment variable manipulation
• Consider disabling PL/Perl extension if not required for business operations

Patch Information

PostgreSQL has released security updates addressing this vulnerability across all supported version branches. Organizations should upgrade to the following minimum versions:

For detailed patch information, consult the PostgreSQL Security Advisory. Additional advisories have been released by Debian LTS and NetApp.

Workarounds

• Revoke PL/Perl usage privileges from non-administrative database users using REVOKE USAGE ON LANGUAGE plperl FROM PUBLIC;
• Drop the PL/Perl extension entirely if not required: DROP EXTENSION IF EXISTS plperl CASCADE;
• Implement strict database role separation to limit which accounts can create procedural language functions
• Use plperlu (untrusted PL/Perl) only for superuser-owned functions and ensure regular plperl restrictions are enforced

-- Revoke PL/Perl privileges from public
REVOKE USAGE ON LANGUAGE plperl FROM PUBLIC;

-- Audit existing PL/Perl functions for environment variable access
SELECT n.nspname AS schema_name,
       p.proname AS function_name,
       pg_get_functiondef(p.oid) AS function_definition
FROM pg_proc p
JOIN pg_namespace n ON p.pronamespace = n.oid
WHERE p.prolang = (SELECT oid FROM pg_language WHERE lanname = 'plperl')
  AND pg_get_functiondef(p.oid) LIKE '%ENV%';