PostgreSQL Fixes 52 Security Vulnerabilities: Code Execution, Data Exposure, and CVE-2026-120154 Explained

A database can be running normally, responding to queries, and passing health checks while silently failing to enforce the security boundaries that protect its data.

That is one of the most important lessons from PostgreSQL's November 2026 security release.

On November 12, 2026, the PostgreSQL Global Development Group released a major security update addressing 52 vulnerabilities and more than 140 bugs across its supported database versions.

The vulnerabilities include arbitrary code execution, SQL injection, unauthorized data access, memory disclosure, and access-control bypasses. Several carry CVSS scores of 8.8, placing them in the high-severity category.

Among them is CVE-2026-120154, a vulnerability that allows database users with specific privileges to read records that should be protected by PostgreSQL's row-level security policies.

The release also addresses problems involving database backups, indexes, replication, and query correctness.

For database administrators, DevOps engineers, and organizations running PostgreSQL in production, this update deserves particular attention. Installing the security patches is essential, but some environments will also require additional database maintenance.

PostgreSQL November 2026 Security Update: Key Details

The complete list of vulnerabilities and fixes is available in the official PostgreSQL release announcement.

The immediate recommendation is to update PostgreSQL to the latest minor release for your major version and review the applicable post-update maintenance instructions.

Which PostgreSQL Versions Are Affected?

The November security release provides fixes for PostgreSQL versions 14 through 18, alongside PostgreSQL 19 RC 2.

Individual vulnerabilities may affect different subsets of these versions. Administrators should consult the PostgreSQL security advisories for vulnerability-specific information.

PostgreSQL 19 RC 2 is a release candidate intended for testing. Production environments should generally use supported stable releases.

PostgreSQL 14 Has Reached End-of-Life

PostgreSQL 14.25 is the final scheduled community release of PostgreSQL 14.

The branch will no longer receive regular upstream security or bug fixes.

Organizations still running PostgreSQL 14 should install the final security update and begin planning a migration to a supported major version.

Unlike minor-version updates, major-version upgrades require additional planning around application compatibility, extensions, backups, replication, and downtime.

See the official PostgreSQL versioning policy for support timelines.

The Most Important PostgreSQL Vulnerabilities in This Release

The 52 vulnerabilities affect multiple components of the PostgreSQL ecosystem, including the database engine, procedural languages, extensions, replication mechanisms, and administrative utilities.

The following selection highlights vulnerabilities with particularly important implications for production infrastructure.

This is a selected list, not the complete set of vulnerabilities.

The important distinction is that these issues do not share a single exploitation mechanism. Some require existing database privileges, while others involve malicious backup archives, compromised replication infrastructure, or administrative operations.

Arbitrary Code Execution and Memory Safety

Several vulnerabilities involve memory-management failures, including type confusion, use-after-free conditions, and buffer overflows.

Under specific conditions, these flaws can allow attackers to execute arbitrary code within the context of an affected PostgreSQL process or administrative utility.

The resulting impact depends on the privileges of that process and the resources accessible to its operating-system account.

Potential consequences include exposure of database contents, configuration files, credentials, and other sensitive resources.

However, arbitrary code execution does not automatically mean unauthenticated remote access or root-level compromise. Each vulnerability has its own prerequisites and security impact.

CVE-2026-120154: PostgreSQL Row-Level Security Bypass Explained

CVE-2026-120154 is a vulnerability in PostgreSQL's handling of INSERT ... ON CONFLICT that allows a database user with specific existing table privileges to read records that should be inaccessible under row-level security policies.

It carries a CVSS score of 4.3, classified as Medium severity.

Despite its comparatively lower score, the vulnerability is particularly important for applications that depend on database-level isolation between customers or organizations.

What Is Row-Level Security?

Row-level security, commonly abbreviated as RLS, is a PostgreSQL feature that controls which individual records a database user can access or modify.

Traditional database permissions determine whether a user can perform operations on a table. RLS adds another layer by determining which rows within that table are accessible.

Consider a SaaS application that stores invoices belonging to multiple organizations in a shared database table.

Although these records exist in the same table, properly configured RLS policies should prevent one organization from accessing another organization's information.

This makes RLS particularly valuable for multi-tenant applications, financial platforms, healthcare systems, and enterprise software.

Learn more in the official PostgreSQL row security documentation.

How Does CVE-2026-120154 Work?

PostgreSQL supports an operation commonly known as an upsert through the INSERT ... ON CONFLICT syntax.

An upsert allows an application to insert a record or perform an alternative operation when an existing record conflicts with a uniqueness constraint.

Applications frequently use this functionality to synchronize data, update records, and prevent duplicate entries.

The vulnerability occurs because certain conflict-handling operations do not correctly enforce row-level security restrictions.

According to the official CVE-2026-120154 advisory, an attacker with the required INSERT, UPDATE, and applicable SELECT privileges on a table can repeatedly perform affected INSERT ... ON CONFLICT DO UPDATE operations to obtain information from rows that RLS policies should hide.

Under the reported conditions, the attacker can ultimately read every row in the affected table.

This is an authorization failure rather than an authentication bypass.

The attacker must already have database access and the necessary table privileges.

CVE-2026-120154 Vulnerability Overview

Importantly, CVE-2026-120154 does not itself enable unauthorized writes or operating-system code execution.

This distinguishes it from CVE-2026-16237, another vulnerability addressed in the same release involving improper access through automatically updatable views.

Why a Medium-Severity Vulnerability Still Matters

A CVSS score describes technical severity, but it cannot fully represent the business impact of a vulnerability.

For a multi-tenant application, allowing one customer to access another customer's confidential information can constitute a significant security incident.

Potential consequences include:

• Exposure of confidential customer information.
• Violations of tenant isolation guarantees.
• Unauthorized access to financial or personal records.
• Regulatory and contractual compliance concerns.
• Loss of customer trust.

The attacker does not need to compromise the entire database server for the incident to become serious.

For organizations relying heavily on RLS, CVE-2026-120154 deserves attention alongside the higher-scoring code execution vulnerabilities.

Why Backup and Replication Systems Also Need Attention

The November PostgreSQL security release affects more than ordinary database queries.

Several vulnerabilities demonstrate how backup restoration and replication infrastructure can become unexpected attack surfaces.

CVE-2026-116314: Malicious Backups and pg_restore

CVSS: 8.8 (High)

The pg_restore utility restores PostgreSQL databases from supported archive formats.

CVE-2026-116314 involves insufficient validation when processing certain non-plain database archives, potentially allowing arbitrary code execution.

This is particularly relevant to organizations restoring backups from external environments, customers, or potentially compromised infrastructure.

A database backup should not automatically be treated as harmless data simply because it is a backup.

Restoration workflows should use patched utilities, trusted archive sources, restricted operating-system privileges, and isolated environments where practical.

Read the CVE-2026-116314 security advisory.

CVE-2026-116330: Command Injection Through Restore Scripts

CVSS: 8.8 (High)

PostgreSQL's pg_dump utility supports tar-format database archives that can include a generated restoration script.

CVE-2026-116330 concerns insufficient protection against injected psql commands in this workflow.

Because psql supports commands that extend beyond ordinary SQL execution, unsafe restoration scripts can introduce risks to the client environment.

Organizations should avoid executing untrusted restoration scripts and ensure that administrative utilities are updated alongside database servers.

Read the CVE-2026-116330 security advisory.

CVE-2026-120145: Logical Replication Code Execution

CVSS: 8.8 (High)

Logical replication transfers selected database changes between PostgreSQL instances.

It is commonly used for migrations, analytics, distributed applications, and data synchronization.

CVE-2026-120145 involves insufficient authorization checks when logical replication applies changes to a subscriber.

A compromised publisher can potentially target a system catalog on the subscriber, leading to arbitrary code execution.

An important limitation is that the reported vulnerability affects subscriptions owned by a PostgreSQL superuser.

Organizations should review subscription ownership, publisher trust relationships, and replication privileges when assessing their exposure.

Read the CVE-2026-120145 security advisory.

How to Check Whether Your PostgreSQL Server Is Affected

Before planning remediation, identify the version of every running PostgreSQL instance.

Connect to the database and execute:

SELECT version();

Alternatively:

SHOW server_version;

You can also check the local PostgreSQL client:

psql --version

Remember that psql --version reports the client version, not necessarily the version of the database server.

This distinction is important when clients and servers are installed on different machines or when multiple PostgreSQL versions coexist.

Check PostgreSQL Administrative Utilities

Because the release also addresses vulnerabilities in backup and maintenance tools, check the versions installed on administrative workstations, backup servers, and CI/CD runners.

pg_dump --version
pg_restore --version
pg_basebackup --version
psql --version

Compare these versions against the applicable security updates provided by your operating system or PostgreSQL package repository.

Identify Tables Using Row-Level Security

Run the following query in each relevant database:

SELECT
    n.nspname AS schema_name,
    c.relname AS table_name,
    c.relrowsecurity AS rls_enabled,
    c.relforcerowsecurity AS rls_forced
FROM pg_class AS c
JOIN pg_namespace AS n
    ON n.oid = c.relnamespace
WHERE c.relkind IN ('r', 'p')
    AND c.relrowsecurity
ORDER BY schema_name, table_name;

This identifies ordinary and partitioned tables with row-level security enabled.

You can also inspect existing policies:

SELECT
    schemaname,
    tablename,
    policyname,
    roles,
    cmd
FROM pg_policies
ORDER BY schemaname, tablename;

These queries help identify where RLS is used. They do not independently establish whether a particular account can exploit CVE-2026-120154 or whether exploitation has already occurred.

Administrators should also review effective table privileges, application roles, and operations involving INSERT ... ON CONFLICT.

How to Patch PostgreSQL's November 2026 Vulnerabilities

The primary remediation is to install the latest patched minor release for your PostgreSQL major version.

For example, PostgreSQL 18 installations should update to version 18.7 or a newer applicable release.

Ordinary PostgreSQL minor-version updates generally do not require dumping and restoring the entire database or running pg_upgrade.

However, this release includes additional maintenance recommendations that should not be overlooked.

Step 1: Prepare and Verify Backups

Before updating production infrastructure:

• Confirm that a recent backup is available.
• Verify that the backup can be restored.
• Review replication health and available disk space.
• Identify applications dependent on the database.
• Schedule an appropriate maintenance window.

Because this release addresses backup integrity problems, existing backups should not automatically be assumed to be valid.

Where possible, perform a restoration test in an isolated environment.

Step 2: Install the Security Updates

On Debian or Ubuntu systems using a repository that provides PostgreSQL 18, an example update is:

sudo apt update

sudo apt install --only-upgrade \
    postgresql-18 postgresql-client-18

For RHEL-compatible systems using PostgreSQL community RPM packages:

sudo dnf upgrade \
    postgresql18-server postgresql18

These commands are examples for PostgreSQL 18. Adjust the package names for your installed major version and repository.

Verify that your package repository provides the patched release or a vendor-supported package containing the relevant security fixes.

For containerized deployments, obtain an updated PostgreSQL image from a trusted registry and recreate the container using your established deployment procedure and existing persistent storage.

For managed database services, follow your provider's maintenance and engine-upgrade instructions.

Step 3: Restart PostgreSQL and Verify the Running Version

After installing the update, ensure PostgreSQL is running the patched binaries.

On installations using the standard PostgreSQL systemd service:

sudo systemctl restart postgresql

The service name may differ depending on your distribution and installation method.

For example, PostgreSQL community RPM installations may use a version-specific service such as postgresql-18.

Production warning: A database restart can interrupt active connections and transactions. Coordinate the restart with application availability requirements, connection pooling, replication, and failover procedures.

High-availability environments should follow their established maintenance process rather than restarting all database nodes simultaneously.

After restarting, reconnect to the database and verify:

SHOW server_version;

Confirm that the running version contains the security fixes.

Also verify application connectivity, replication health, scheduled jobs, and monitoring.

Step 4: Complete Required Post-Update Maintenance

This is one of the most important aspects of the November 2026 PostgreSQL release.

Installing patched binaries prevents the corrected behavior from recurring, but it does not automatically repair previously affected database structures or backups.

The official release announcement identifies several circumstances requiring additional action.

The applicability of these actions depends on your PostgreSQL version and database configuration.

For example, an affected index can be rebuilt using:

REINDEX INDEX your_index_name;

Where supported and appropriate, concurrent reindexing can reduce disruption:

REINDEX INDEX CONCURRENTLY your_index_name;

To rebuild the indexes associated with an affected table:

REINDEX TABLE your_table_name;

Reindexing can consume substantial CPU, storage, and I/O resources. It may also affect concurrent database operations.

Review locking behavior and available disk space before performing these operations in production.

See the PostgreSQL REINDEX documentation for syntax, limitations, and operational considerations.

Step 5: Create a New Full Backup if Using Incremental Backups

PostgreSQL recommends that users of incremental backups create a new full backup after updating.

Subsequent incremental backups should use this new full backup as their foundation.

This recommendation follows fixes for issues that could affect backup integrity.

A successful backup job does not necessarily prove that the resulting backup can be restored accurately.

Where possible, validate the new backup through an isolated restoration test.

See the PostgreSQL backup and restore documentation for additional guidance.

Step 6: Update Administrative and Backup Tools

Do not overlook systems that connect to PostgreSQL for maintenance.

Review and update applicable installations of:

• psql
• pg_dump
• pg_restore
• pg_basebackup
• vacuumdb
• reindexdb

These tools may run on separate backup servers, administrative workstations, CI/CD runners, or container images.

Updating only the primary database server may leave other vulnerable components in your infrastructure.

For the complete version-specific instructions, consult the official November release announcement and PostgreSQL release notes.

What If You Cannot Patch Immediately?

Temporary security controls can reduce exposure while an update is being prepared.

Consider the following measures:

• Restrict database access to trusted application servers and administrative networks.
• Review database roles and remove unnecessary privileges.
• Restrict potentially affected upsert operations where practical.
• Review superuser-owned logical replication subscriptions.
• Avoid restoring backups or executing SQL scripts from untrusted sources.
• Isolate administrative and restoration environments where possible.
• Monitor unusual database activity and unexpected changes.

These measures are defense-in-depth controls, not complete fixes.

Because the release addresses multiple unrelated vulnerabilities, no single configuration change can replace the patched software.

Have These PostgreSQL Vulnerabilities Been Exploited in the Wild?

The official November 12 release confirms the vulnerabilities and the availability of security fixes.

However, the announcement does not establish widespread active exploitation of the disclosed vulnerabilities.

Administrators should distinguish between a disclosed vulnerability, a publicly demonstrated exploit, and confirmed compromise of production systems.

The appropriate response is to prioritize remediation based on affected components, existing privileges, infrastructure exposure, and the sensitivity of stored data.

Waiting for widespread exploitation reports before applying available security updates can unnecessarily extend the period of exposure.

What This Means for DevOps and Cloud Infrastructure

PostgreSQL is frequently the central component of modern application infrastructure.

A single database cluster may support authentication systems, customer applications, financial records, analytics pipelines, and internal automation.

The November 2026 security release reinforces three important operational principles.

Database Security Extends Beyond Authentication

Strong passwords, encrypted connections, and private networks remain essential.

However, CVE-2026-120154 demonstrates that security weaknesses can also exist in the mechanisms that enforce data access after authentication.

Security reviews must consider what users can do after connecting, not just whether they can connect.

Backups Must Be Tested, Not Merely Created

A backup is valuable only if it can be restored accurately and safely.

Organizations should maintain regular restoration tests, review backup-tool versions, and ensure their recovery procedures account for security updates.

Patch Management Must Cover the Entire Ecosystem

A PostgreSQL deployment includes more than the database server.

Replicas, extensions, administrative utilities, backup infrastructure, and container images may also require updates.

For organizations operating multiple VPS instances or distributed cloud infrastructure, maintaining an accurate software inventory is an important part of effective patch management.

Frequently Asked Questions

Final Thoughts

The November 2026 PostgreSQL security release is a reminder that database security is not limited to preventing unauthorized connections.

It also depends on the correct enforcement of permissions, safe handling of database objects, trustworthy backups, reliable replication, and accurate query results.

CVE-2026-120154 demonstrates how an authorization flaw can undermine the isolation of sensitive customer information, even when authentication and network security are functioning correctly.

Meanwhile, the higher-severity code execution vulnerabilities highlight why the broader PostgreSQL ecosystem must be included in every infrastructure security review.

For database administrators and DevOps teams, the priorities are clear:

Update PostgreSQL, patch administrative utilities, verify the running version, complete applicable post-update maintenance, and validate your backups.

At ShellSecrets, we believe dependable infrastructure requires more than keeping services online. It requires protecting the data, systems, and operational processes that businesses depend on.

Whether you operate a single PostgreSQL instance or a distributed production environment, proactive maintenance remains one of the most effective ways to reduce security risks.

A database that is available but cannot guarantee the confidentiality or integrity of its data is not truly reliable.

References and Further Reading

1. PostgreSQL — November 12, 2026 Security Release Announcement
2. PostgreSQL — CVE-2026-120154 Security Advisory
3. CVE Program — CVE-2026-120154
4. PostgreSQL — CVE-2026-116314 Security Advisory
5. PostgreSQL — CVE-2026-116330 Security Advisory
6. PostgreSQL — CVE-2026-120145 Security Advisory
7. PostgreSQL Security Advisories
8. PostgreSQL Official Release Notes
9. PostgreSQL Row Security Policies
10. PostgreSQL Versioning Policy