Escaping Managed PostgreSQL: Exploiting Environment Variables via PL/Perl and PL/Rust

TLDR: Researchers at DEF CON 2025 demonstrated a privilege escalation and remote code execution technique against managed PostgreSQL instances, specifically targeting AWS RDS. By abusing the PL/Perl and PL/Rust language extensions, an attacker can manipulate environment variables like CARGO_BUILD_RUSTC_WRAPPER to execute arbitrary system commands. This research highlights the critical risk of enabling untrusted language extensions in cloud-managed database environments and provides a clear path for testing similar configurations.

Managed database services are often treated as black boxes. We assume that because the cloud provider manages the underlying infrastructure, the attack surface is limited to the database engine itself. This assumption is dangerous. When you enable language extensions like PL/Perl or PL/Rust, you are effectively extending the database's capabilities into the host operating system. If those extensions are not properly sandboxed, a standard database user can pivot from executing SQL queries to executing arbitrary code on the underlying host.

The research presented at DEF CON 2025 regarding CVE-2024-10979 proves that even in highly locked-down environments like AWS RDS, these extensions can be weaponized. The core of the issue lies in how these extensions handle environment variables. If an extension allows a non-superuser to modify the environment of the database process, the security boundary is effectively gone.

The Mechanics of the Escape

The attack flow relies on the fact that PL/Perl and PL/Rust are designed to be extensible. PL/Perl, for instance, provides access to "magic" variables that interact with the process environment. By creating a function that modifies these variables, an attacker can influence the behavior of subsequent processes spawned by the database.

The researchers identified that when a PL/Rust function is created, it invokes the Cargo package manager to compile the code. Cargo, in turn, relies on environment variables to determine how to build the project. By using PL/Perl to modify the CARGO_BUILD_RUSTC_WRAPPER environment variable, the researchers forced Cargo to execute a binary of their choosing instead of the standard Rust compiler.

Consider this simplified payload structure used to modify the environment:

CREATE OR REPLACE FUNCTION set_env(text, text)
RETURNS void AS $$
    $ENV{$_[0]} = $_[1];
$$ LANGUAGE plperl;

SELECT set_env('CARGO_BUILD_RUSTC_WRAPPER', '/tmp/malicious_binary');

Once the environment variable is set, any subsequent attempt to compile a PL/Rust function triggers the execution of the specified binary. This is a classic Command Injection scenario, but one that is hidden deep within the database's build pipeline.

Why This Matters for Pentesters

During a penetration test or a bug bounty engagement, you should never ignore the extensions enabled on a database. If you find a PostgreSQL instance where you have the permissions to create functions, check which languages are available. If plperl or plrust are installed, you have a high-probability path to code execution.

The impact of this vulnerability is severe. It allows an attacker to move from a restricted database user to the context of the database service account on the host. In a cloud environment, this often means the attacker can access local files, attempt to exfiltrate cloud credentials stored in the environment, or pivot to other services within the same VPC.

When testing, focus on the pg_extension table to see what is installed. If you see plperl or plrust, your next step is to determine if you have the necessary privileges to create functions. If you do, you are not just querying data; you are potentially owning the host.

Defensive Hardening

Defending against this requires a strict adherence to the principle of least privilege. If your application does not require the ability to create custom functions or load extensions, disable those capabilities entirely. For managed services, use the provider's configuration parameters to restrict the list of allowed extensions.

AWS RDS, for example, allows you to configure the rds.allowed_extensions parameter. If you are not using PL/Perl or PL/Rust, ensure they are not in that list. Furthermore, monitor your database logs for unusual function creation activity. An attacker needs to create these functions to facilitate the exploit, and that action should trigger an alert in any well-configured security operations center.

Moving Beyond the Database

This research is a reminder that the cloud is not a magic shield. Every extension you enable, every configuration you tweak, and every permission you grant adds a new layer to your attack surface. When you are auditing a cloud environment, look for the "obscure" features. The most interesting bugs are rarely found in the main SQL query interface; they are found in the features that bridge the gap between the database and the underlying operating system.

If you are a researcher, start by looking at how these extensions interact with the host. If you are a defender, start by auditing your database configurations to ensure that only the bare minimum of functionality is exposed. The gap between a database user and a system shell is often smaller than you think. Keep digging into these extensions, because the next privilege escalation is likely hiding in the next "feature" that was enabled for convenience.