CVE-2023-2454 - How `schema_element` Defeats Protective `search_path` Changes in PostgreSQL

In June 2023, the PostgreSQL team published a critical security advisory: CVE-2023-2454. This vulnerability highlights a subtle but powerful weakness in how PostgreSQL database handles search_path when certain database calls are performed. Even if you’ve previously hardened your search_path settings to prevent untrusted code execution, this CVE proves attackers can still slip through — using schema_element in crafty ways.

If you run apps or services that give *high database-privilege* roles to users, you should read this carefully.

TL;DR

- Attackers with certain database-level privileges can use the schema_element syntax to run arbitrary code, bypassing safety controls you may have added.

This works even if you have set search_path to a trusted value.

- This post explains the root cause, demonstrates with code, and offers hard-earned tips on mitigation.

How Does schema_element Work?

A schema_element in PostgreSQL is anything you can define within a schema — tables, functions, operators, etc. When you call functions like CREATE or ALTER in SQL, you're playing with schema elements.

But there’s a subtlety: When you reference an object (say a function), Postgres searches for it in the schemas listed in your search_path. Many guides recommend locking down the search_path or setting it to a secure default as a way to prevent exploitation, since malicious code often lurks in the “public” schema by default.

Problem: Certain system calls and DDL (data definition language) statements can *reference objects by explicit schema name*, and some internal PostgreSQL code did not check search_path as tightly as people assumed.

Any app that allows elevated database users to run DDL or reference user-defined objects by name

If you let users define functions, tables, or even run procedural code of any sort (PL/pgSQL, PL/Python, PL/Perl, etc.), and they are not fully trusted, *read on—you are at risk*.

Exploitation: Code Example

Suppose you want to let a trusted extension or user create temporary tables, but you’ve locked down your search_path to pg_catalog to avoid any shadowing or malicious function injection.

An attacker creates a *malicious function* in a less-trusted schema, say, evil.

-- Attacker creates a function in 'evil' schema
CREATE SCHEMA evil;
CREATE FUNCTION evil.do_bad() RETURNS void AS $$
BEGIN
  -- maybe run arbitrary OS commands
END;
$$ LANGUAGE plpgsql;

As a system DBA, you correctly set your search_path

SET search_path = pg_catalog;

Then, you or your code runs a DDL that references the attacker’s schema by full path

-- This will explicitly call the evil schema’s function
SELECT evil.do_bad();

Even though you "thought" your search path protected you, fully qualified schema references allow execution of code anywhere the user has USAGE rights. The CVE exploit lies in the ability for attackers to "escape" the protected environment.

Original Reference

- PostgreSQL Security Advisory - CVE-2023-2454
- Red Hat Security Update
- Debian Security Tracker

Analysis: Why Did This Happen?

*Summary*: The assumption that search_path alone prevents object reference abuse is incorrect. Even with a hardened search path, users can call functions/tables directly via schema_name.object_name. PostgreSQL’s permission model doesn’t stop this if the user has sufficient privileges.

Additionally, certain DDL (like ALTER ... OWNER, CREATE FUNCTION ... AS, etc.) could reference objects in unexpected schemas if not closely controlled.

Exploit: A Realistic Exploit Pattern

Let’s look at a slightly more practical example, where an attacker uses a presiding privilege to plant malicious code:

-- Attacker with CREATE rights on a schema injects code
CREATE SCHEMA evil;
CREATE TABLE evil.secret_data (id serial, contents text);
CREATE FUNCTION evil.leak() RETURNS void AS $$
BEGIN
  -- exfiltrate data or perform lateral movement
  INSERT INTO evil.secret_data(contents) VALUES ('Exfiltrated from admin');
END;
$$ LANGUAGE plpgsql;

-- Later, a privileged routine *somewhere in* your codebase runs:
DO
$$
BEGIN
  -- trusted code, but accidentally calls full schema path, or auto-discovered
  PERFORM evil.leak();
END;
$$ LANGUAGE plpgsql;

Here, the code executes malicious logic regardless of your configured search_path, since the schema was specified. If the attacking user was granted generic “developer” rights to a schema, they can *break out* of your intended sandbox.

Mitigation: How To Protect Yourself

1. Review Privileges — Never grant elevated users CREATE or USAGE on low-trust schemas (like public) unless you must.

Schema Ownership Rules — Restrict who may create new schemas or deploy code into them.

3. Function Call Patterns — Avoid using explicit schema references unless you can guarantee the code within is audited and trusted.
4. Policies & Extensions — Use Row Level Security (RLS), and consider security-oriented extensions like pgaudit to log suspicious function calls.
5. Upgrade PostgreSQL — Always run a version with backports or security patches, as the PostgreSQL team addressed this flaw in new releases.

Helpful link: PostgreSQL Role and Privilege Management

Final Word: What This Means

CVE-2023-2454 reminds us: setting a safe search_path is necessary but not sufficient for privilege separation. Always consider the full scope of how users and routines can reference schema elements. Harden your schema access policy, deploy least privilege, and review "trusted code" for any explicit schema references. Your database's security, data privacy, and the reliability of your apps depend on it.

If you must allow user-defined code, keep it isolated, sandboxed, and monitored: don't count on search_path alone to save you.

References for Further Reading

- PostgreSQL Search Path Docs
- CVE-2023-2454 Advisory

Timeline

Published on: 06/09/2023 19:15:00 UTC
Last modified on: 06/16/2023 18:00:00 UTC