CVE-2026-6472

What it actually does

CVE-2026-6472 is a PostgreSQL authorization bypass involving CREATE TYPE and type resolution through search_path. A low-privileged database user who can create objects can define a malicious user-defined type and associated SQL functions in a schema that is searched before the intended schema. When another user, application query, or extension-related operation resolves a type name through search_path, PostgreSQL may bind to the attacker-controlled type or function path, causing the victim session to execute SQL functions chosen by the attacker. The impact is constrained by database privileges and execution context, but can result in unauthorized data access or data modification within PostgreSQL.

Why it matters to the business

An attacker with limited database access may be able to interfere with application queries or database extension behavior and cause trusted database sessions to run attacker-controlled SQL. In business terms, this can lead to unauthorized viewing or alteration of data, incorrect application behavior, and loss of confidence in database integrity. The CVSS score is moderate and EPSS is currently low, with no known CISA KEV listing or ransomware association, but PostgreSQL is widely deployed and the issue is especially important in shared databases, multi-tenant database platforms, environments that allow application roles to create database objects, and systems that rely heavily on extensions or unqualified type names.

How an attack unfolds

An attacker first obtains authenticated access to a PostgreSQL database using an account that has permission to create schemas, types, or functions. The attacker then creates a malicious user-defined type and supporting SQL functions in a schema that can appear earlier in another session's search_path than the legitimate schema containing the intended type, including scenarios involving extension-defined types. The attacker waits for or induces a victim query, application workflow, administrative task, or extension-related operation that refers to the type without a fully qualified schema name. PostgreSQL resolves the type name according to search_path, selects the attacker-controlled object, and invokes attacker-supplied SQL functions during normal query execution. The resulting SQL executes in the context allowed by PostgreSQL semantics for that operation, potentially exposing data, changing records, or altering downstream query behavior.

How to fix it

Upgrade PostgreSQL to a fixed release: PostgreSQL 18.4 or later, 17.10 or later, 16.14 or later, 15.18 or later, or 14.23 or later. If immediate upgrade is not possible, reduce exposure by revoking unnecessary CREATE privileges on databases and schemas from untrusted roles, especially PUBLIC; enforcing secure search_path settings that prioritize trusted schemas and avoid attacker-writable schemas; schema-qualifying type names and extension objects in application SQL where feasible; isolating tenants or applications into separate databases or tightly controlled schemas; and reviewing extension installation and ownership practices. Treat mitigation as defense-in-depth only; the durable fix is to apply the PostgreSQL maintenance release for the deployed major version.

How to confirm the fix worked

Confirm the running PostgreSQL server version with SELECT version(); or SHOW server_version; and verify it is at least 18.4, 17.10, 16.14, 15.18, or 14.23 depending on the installed major release. Inventory database roles and schemas to ensure untrusted users do not have CREATE privileges in databases or schemas that appear in application search_path values. Review ALTER ROLE, ALTER DATABASE, and session-level search_path settings to confirm attacker-writable schemas are not searched before trusted schemas. Validate application SQL and database routines for unqualified references to user-defined or extension-defined types in security-sensitive code paths. After patching, run regression tests for applications and extensions that use custom types to confirm normal type resolution and query behavior.

Typical attack path

1. Gain authenticated low-privileged access to a PostgreSQL database.
2. Identify databases or roles where CREATE privileges allow user-defined schemas, types, or functions.
3. Inspect or infer commonly used search_path settings and unqualified type references used by applications or extensions.
4. Create an attacker-controlled type and associated SQL functions in a schema likely to be resolved before the intended schema.
5. Wait for or trigger a victim query or application operation that resolves the type name through search_path.
6. Cause the victim session to execute attacker-selected SQL functions through PostgreSQL type/function resolution.
7. Use the execution opportunity to read accessible data, modify records, alter application behavior, or establish further database-level persistence where privileges permit.

How to detect it

Investigate PostgreSQL audit logs, statement logs, DDL logs, and extension management records for unexpected CREATE TYPE, CREATE FUNCTION, CREATE SCHEMA, ALTER ROLE SET search_path, ALTER DATABASE SET search_path, or SET search_path activity by non-administrative accounts. Focus on the period before patching and on databases where application roles, developers, tenants, or other low-privileged users had CREATE permissions. Review pg_type, pg_proc, pg_namespace, pg_roles, and privilege metadata for user-defined types and functions created by unusual owners, created in schemas that appear early in search_path, or named similarly to extension-defined or application-defined types. If pgAudit or equivalent logging is enabled, correlate DDL creation events with subsequent victim sessions executing queries that reference unqualified custom types or invoke unexpected functions. There are no public reports of exploitation, no KEV listing, and no named threat actors in the supplied data, so detection should focus on behavioral artifacts rather than known malware or network indicators.

• CREATE TYPE
• CREATE FUNCTION
• CREATE SCHEMA
• ALTER ROLE SET search_path
• ALTER DATABASE SET search_path
• SET search_path
• pg_type
• pg_proc
• pg_namespace
• REVOKE CREATE ON SCHEMA public FROM PUBLIC
• GRANT CREATE ON SCHEMA public

What your security team should do

• Prioritize patching PostgreSQL instances where untrusted or semi-trusted users can create database objects, including shared application databases, developer-accessible databases, hosted database platforms, and multi-tenant environments.
• Upgrade affected PostgreSQL major versions to 18.4+, 17.10+, 16.14+, 15.18+, or 14.23+ as applicable.
• Immediately audit and restrict CREATE privileges on databases and schemas; revoke CREATE on public or shared schemas from PUBLIC and non-administrative roles where not required.
• Review role-level and database-level search_path settings for unsafe ordering or inclusion of schemas writable by non-administrative users.
• Search for suspicious recently created types and functions owned by low-privileged roles, especially in schemas that appear in application search_path values.
• Increase PostgreSQL logging temporarily for DDL and function execution where operationally feasible to support investigation and validation.
• Schema-qualify user-defined and extension-defined type references in high-risk application SQL, stored procedures, and administrative scripts.
• Monitor for abnormal DDL activity, unexpected function creation, or query behavior changes involving custom types.