CVE-2026-6638

What it actually does

This vulnerability is a SQL injection flaw in PostgreSQL logical replication subscription refresh handling. In affected PostgreSQL 16, 17, and 18 minor releases, a user who can create subscriber-side tables can craft object metadata that is later incorporated unsafely when `ALTER SUBSCRIPTION ... REFRESH PUBLICATION` runs. When the refresh occurs, the injected SQL can execute using the credentials configured for the subscription’s connection to the publication-side database. The practical impact is limited by the privileges of that publication-side replication user, but those privileges may include read access to published tables and, in poorly constrained deployments, broader database modification or administrative rights.

Why it matters to the business

Organizations using PostgreSQL logical replication on affected versions may have a trust-boundary issue between subscriber-side database users and the publisher database. A low-privileged user on a subscriber can potentially cause unauthorized SQL to run against the publisher during a subscription refresh, which could expose data, alter database objects, or weaken database access controls depending on the replication user’s privileges. The CVSS and EPSS values indicate lower general exploitation likelihood, and it is not listed in CISA KEV, but the issue is important in shared database, multi-team, hosting, SaaS, or delegated administration models where untrusted users can create tables on subscribers.

How an attack unfolds

An attacker first needs authenticated access to an affected PostgreSQL 16, 17, or 18 subscriber database with enough privilege to create tables or otherwise influence subscriber-side table metadata used by logical replication. The attacker creates a specially crafted table, schema, or identifier intended to break out of the SQL generated during publication refresh processing. The vulnerability does not trigger immediately; it takes effect when `ALTER SUBSCRIPTION ... REFRESH PUBLICATION` is executed for the affected subscription, either by an administrator, automation, deployment process, or maintenance task. During that refresh, the subscriber contacts the publisher using the subscription’s configured connection credentials. PostgreSQL then processes the malicious metadata and may execute attacker-supplied SQL on the publication-side database under those credentials. The attacker’s resulting access is constrained by what the publication-side user can do, but if that account is overprivileged, the attacker may read non-publication data, modify database objects, create new roles or grants, or establish persistence inside the database.

How to fix it

Upgrade affected PostgreSQL major versions to fixed minor releases: PostgreSQL 18.4 or later, PostgreSQL 17.10 or later, and PostgreSQL 16.14 or later. PostgreSQL versions before 16 are described as unaffected. If immediate upgrade is not possible, restrict who can create tables or schemas on subscriber databases, especially in databases participating in logical replication. Review all logical replication subscription connection users on the publisher and ensure they follow least privilege: avoid superuser, avoid broad DDL privileges, avoid role administration permissions, and grant only the access required for publication replication. Limit who can run `ALTER SUBSCRIPTION ... REFRESH PUBLICATION`, and pause nonessential subscription refresh automation until patched. Audit existing subscriber-side schemas and tables for unusual quoted identifiers, SQL metacharacters, or objects created by untrusted users before running refresh operations.

How to confirm the fix worked

Confirm the running PostgreSQL minor version with `SELECT version();` or package manager inventory and verify that all PostgreSQL 16, 17, and 18 instances are at 16.14+, 17.10+, or 18.4+. Inventory logical replication usage by checking for subscriptions on subscriber databases and publications on publisher databases. Validate that subscription connection strings use minimally privileged publication-side users. Review role grants to ensure untrusted users cannot create objects in schemas involved in logical replication. In a non-production test environment, confirm that subscription refresh operations still succeed after upgrade and that suspicious crafted identifiers are rejected or safely handled. If patching cannot be completed immediately, confirm compensating controls by demonstrating that only trusted administrative roles can create subscriber-side tables and run subscription refresh commands.

Typical attack path

1. Identify an affected PostgreSQL 16, 17, or 18 environment using logical replication subscriptions.
2. Obtain low-privileged authenticated access on the subscriber database with permission to create tables or schemas.
3. Create a crafted subscriber-side table, schema, or identifier designed to inject SQL during publication refresh processing.
4. Wait for or induce an administrator, job, or deployment process to run `ALTER SUBSCRIPTION ... REFRESH PUBLICATION`.
5. Have the injected SQL execute against the publisher using the subscription’s configured publication-side credentials.
6. Use the privileges of that publication-side account to read data, alter objects, change permissions, or prepare further database-level actions.

How to detect it

Detection should focus on the relationship between subscriber-side object creation and subsequent subscription refresh activity. Review PostgreSQL logs on subscriber databases for `CREATE TABLE`, `CREATE SCHEMA`, and other DDL executed by low-privileged users shortly before `ALTER SUBSCRIPTION ... REFRESH PUBLICATION`. Look for quoted identifiers containing SQL metacharacters such as semicolons, comments, dollar-quoted strings, or keywords that would be unusual in object names. On publisher databases, review statements executed by the subscription connection user during the same time window and identify commands unrelated to logical replication, such as role changes, grants, extension creation, table modification outside expected publication maintenance, file access, or suspicious function calls. Useful log sources include PostgreSQL server logs, pgaudit logs if enabled, database activity monitoring tools, connection logs for replication users, and administrative job logs that perform subscription refreshes. Correlate suspicious publisher-side SQL with refresh timestamps and subscriber-side object creation by the same database, subscription, or operational workflow. Because there are no public exploit-specific artifacts in the provided intelligence, absence of these strings does not prove absence of exploitation; prioritize behavioral correlation and privilege review.

• ALTER SUBSCRIPTION
• REFRESH PUBLICATION
• CREATE TABLE
• CREATE SCHEMA
• COPY PROGRAM
• pg_sleep(
• CREATE EXTENSION
• ALTER ROLE
• CREATE ROLE
• GRANT
• REVOKE
• SECURITY DEFINER
• --
• /*
• */
• $$
• ;
• logical replication
• subscription
• publication

What your security team should do

• Prioritize patching PostgreSQL 16, 17, and 18 systems that use logical replication, especially where subscriber databases are writable by non-administrative or semi-trusted users.
• Upgrade to PostgreSQL 18.4+, 17.10+, or 16.14+ according to the deployed major version.
• Inventory all logical replication subscriptions and identify the publication-side credentials used by each subscription.
• Reduce privileges of replication connection users so compromise through this flaw cannot become broad database compromise.
• Temporarily restrict or monitor `ALTER SUBSCRIPTION ... REFRESH PUBLICATION` until affected systems are upgraded.
• Audit subscriber-side object creation before recent refresh operations, focusing on unusual quoted identifiers and SQL metacharacters in table or schema names.
• Enable or increase PostgreSQL statement logging for administrative DDL and replication maintenance activity where operationally feasible.
• Search publisher logs for unexpected SQL executed by replication or subscription connection users around the time of subscription refreshes.
• Treat suspicious refresh activity as a potential publisher-side credential compromise and rotate affected publication-side credentials after containment.