CVE-2026-6476

What it actually does

This is a SQL injection flaw in PostgreSQL's pg_createsubscriber utility affecting PostgreSQL 17.x before 17.10 and 18.x before 18.4. A database principal that already has pg_create_subscription privileges can craft subscription-related state that is later processed unsafely by pg_createsubscriber. When the utility is next executed, attacker-controlled SQL can run with superuser privileges, allowing full database compromise, including reading or modifying data, changing roles, altering configuration, installing extensions, and disrupting service. PostgreSQL versions before 17 are not affected.

Why it matters to the business

Successful exploitation can turn a privileged-but-not-superuser database account into full administrative control over the PostgreSQL instance. In business terms, this can lead to exposure or alteration of sensitive data, unauthorized creation of powerful database accounts, replication abuse, service disruption, failed compliance obligations, and costly incident response. The likelihood is reduced because the attacker needs pg_create_subscription rights and the vulnerable utility must be run, and there is no known KEV listing or mature public exploit based on the provided data; however, the impact is high for organizations using PostgreSQL 17 or 18 with delegated subscription management.

How an attack unfolds

An attacker first obtains or already has access to a PostgreSQL role with pg_create_subscription capability. The attacker then creates or modifies subscription-related database objects in a way that embeds malicious SQL into data later consumed by pg_createsubscriber. The attack does not necessarily execute immediately; it becomes active when an administrator, automation job, or maintenance workflow next runs pg_createsubscriber against the affected database. Because the vulnerable utility executes the constructed SQL in a superuser context, the injected statements can perform actions the attacker could not normally perform, such as creating a superuser role, changing permissions, reading restricted data, modifying application tables, or damaging availability. The delayed execution model makes this suitable for persistence and privilege escalation after an initial database credential compromise.

How to fix it

Upgrade affected PostgreSQL deployments to a fixed minor release: PostgreSQL 18.x should be upgraded to 18.4 or later, and PostgreSQL 17.x should be upgraded to 17.10 or later. PostgreSQL versions before 17 are not affected by this issue. Ensure both server packages and client/admin utility packages that include pg_createsubscriber are updated. Until patching is complete, avoid running pg_createsubscriber against databases where pg_create_subscription has been granted to non-fully-trusted roles, revoke unnecessary pg_create_subscription privileges, and tightly control who can create or modify subscriptions. If exploitation is suspected, review roles, permissions, subscriptions, publications, extensions, database configuration changes, and recent superuser activity before returning the system to normal operation.

How to confirm the fix worked

Confirm the installed PostgreSQL major and minor version using version-reporting commands such as SELECT version(); or SHOW server_version;, and verify that PostgreSQL 17 installations are at 17.10 or later and PostgreSQL 18 installations are at 18.4 or later. Validate package manager output and the pg_createsubscriber binary version on hosts where PostgreSQL administrative utilities are installed. Review role memberships to ensure pg_create_subscription is granted only to trusted administrators. Confirm that automation, replication, and migration workflows no longer invoke an unfixed pg_createsubscriber binary. For exposure validation, inventory all PostgreSQL 17 and 18 instances and identify any database where non-superuser roles can create subscriptions.

Typical attack path

1. Gain authenticated access to PostgreSQL with a role that has pg_create_subscription privileges.
2. Create or alter subscription-related objects or metadata containing SQL designed to be interpreted by pg_createsubscriber.
3. Wait for an administrator, scheduled task, migration, replication setup, or maintenance workflow to run pg_createsubscriber.
4. Have the malicious SQL execute in the pg_createsubscriber superuser context.
5. Use the resulting superuser access to create persistent privileged roles, exfiltrate data, modify records, alter configuration, or disrupt the database service.

How to detect it

Review PostgreSQL logs, database audit logs, operating system process execution logs, EDR telemetry, and administrative automation logs. Focus on the period before and during any pg_createsubscriber execution. Look for CREATE SUBSCRIPTION, ALTER SUBSCRIPTION, DROP SUBSCRIPTION, and related replication object activity by roles that are not normal database administrators. Correlate those events with subsequent superuser actions, such as CREATE ROLE ... SUPERUSER, ALTER ROLE privilege changes, GRANT statements, extension installation, configuration changes, COPY-based data export, unusual schema changes, or destructive DDL. On hosts, search shell history, cron/systemd timers, CI/CD logs, and process telemetry for pg_createsubscriber invocations. Because exploitation is delayed until pg_createsubscriber runs, pay special attention to subscription changes that occurred before the utility execution and privileged changes immediately after it. If threat hunting finds unexpected superuser creation, unexplained role grants, or suspicious DDL following pg_createsubscriber activity, preserve logs and perform full database incident response.

• pg_createsubscriber
• CREATE SUBSCRIPTION
• ALTER SUBSCRIPTION
• DROP SUBSCRIPTION
• pg_create_subscription
• GRANT pg_create_subscription
• CREATE ROLE
• ALTER ROLE
• SUPERUSER
• REPLICATION
• CREATE EXTENSION
• COPY
• PROGRAM

What your security team should do

• Prioritize patching PostgreSQL 17.x and 18.x systems that use logical replication, subscriptions, or pg_createsubscriber workflows.
• Upgrade PostgreSQL 18.x to 18.4 or later and PostgreSQL 17.x to 17.10 or later, including client/admin utility packages.
• Revoke pg_create_subscription from any role that does not strictly require it, especially application, service, developer, and shared operational accounts.
• Audit recent CREATE SUBSCRIPTION, ALTER SUBSCRIPTION, DROP SUBSCRIPTION, and pg_createsubscriber activity for suspicious timing or unexpected operators.
• Inspect PostgreSQL roles for newly created superusers, unexpected privilege grants, changed passwords, new replication privileges, and unauthorized role memberships.
• If suspicious activity is found, treat the database as potentially fully compromised: preserve logs, rotate database credentials, review data access, and rebuild trust in administrative accounts and replication configurations.
• Add monitoring for future pg_create_subscription grants and pg_createsubscriber executions so that privilege escalation attempts are not missed.