PostgreSQL receives out-of-cycle patch for 28 critical vulnerabilities, including remote code execution

Postgres Professional, a company behind one of PostgreSQL's corporate forks, has released out-of-cycle security updates that close 28 critical vulnerabilities and more than 110 bugs found in PostgreSQL. According to a CNews report, some of these flaws allow a remote attacker to take control of the database server, which in practice puts at risk the entire infrastructure where the DBMS runs.

The point that matters for anyone running PostgreSQL in production in Brazil is that these fixes originate in the upstream project: the Russian fork simply ported them first to its Enterprise edition. In other words, the CVEs mentioned affect the PostgreSQL ecosystem as a whole, not a niche product. If you maintain instances in production, it's worth following the project's official security announcement and the bulletin from your distribution or cloud provider.

Three risk groups

The release organizes the flaws by type of business impact. It's worth understanding the difference, because each category changes the urgency calculation.

1. Arbitrary code execution (RCE). This is the most severe group, with flaws rated CVSS 8.8, which allow remote code execution on the server. It includes buffer overflow vulnerabilities and type confusion flaws:

| CVE | Component | Type | |---|---|---| | CVE-2026-14664 | regular expression processing | buffer overflow | | CVE-2026-14669 | to_char() function | buffer overflow | | CVE-2026-14670 | PL/Perl | buffer overflow | | CVE-2026-14676 | pg_stat_statements | buffer overflow | | CVE-2026-19385 | pg_dump | buffer overflow | | CVE-2026-14671 | plan cache in contrib/refint | type confusion | | CVE-2026-14680 | internal arguments | type confusion | | CVE-2026-16238 | pg_restore_attribute_stats() | type confusion | | CVE-2026-16239 | CLOSE + DECLARE of cursors | type confusion |

It's notable that everyday components appear on this list: pg_dump and pg_stat_statements are part of the routine for any team doing logical backups or query observability.

2. Unauthorized data access. Includes SQL injections that allow bypassing access control and reading data without permission. The highlight is CVE-2026-15741, which enables SQL injection through the EXTRACT() argument during expression deparsing.

3. Operating system command execution. Flaws that escape the DBMS and reach the server shell:

• CVE-2026-18408: shell command execution via psql \unrestrict during dump restoration.
• CVE-2026-6471: loading of arbitrary libraries during logical decoding. The fix restricts allowed modules to the output_plugin_libraries parameter.
• CVE-2026-6464: in an early COPY FROM STDIN failure, data lines can be interpreted as psql commands, opening a path to shell-level execution.

Why "out-of-cycle" matters

The company deliberately separated security fixes from feature updates. The rationale, given by CTO Yulia Rydenkova, is to reduce the risk of touching an application that already works just to close a hole:

For business systems, it's important not only to close security threats quickly, but also to keep the operation predictable. That's why we release security updates separately from functional ones. The customer can install the necessary fixes immediately, without waiting for the next planned update and without introducing new features at the same time.

>

-- Yulia Rydenkova, CTO of Postgres Professional

This logic is familiar to anyone who administers databases: applying a security patch shouldn't drag along a change in planner behavior or features. It's the same backport principle that Linux distributions and the PostgreSQL upstream project itself follow in maintenance releases (the ones that only change the last version number).

What changes when updating

An operational relief: according to the material, the installation does not require pg_upgrade or exporting/importing databases. Just:

# stop the server
# replace the binaries
# restart the server

Downtime tends to be minimal and doesn't depend on lengthy negotiation with data owners, something that in a DBA's routine greatly reduces the friction of scheduling the maintenance window.

The part that can't be ignored is the recommended checks after the update, because some fixes touch the internal data representation of indexes:

• GIN indexes: review tables with these indexes and, if necessary, run ANALYZE to update statistics, which keeps the query planner accurate.
• btree_gist indexes: reindex indexes on columns of types float4, float8, bit, and bit varying. The change may affect the internal format, and reindexing ensures consistency.
• B-tree indexes on ltree: reindex when values have more than 14,653 labels; above that limit, indexes may operate incorrectly.
• Logical decoding: review the configuration and add trusted plugins to the output_plugin_libraries parameter. This is especially relevant for those using replication or CDC solutions based on logical decoding, a scenario increasingly common in Brazilian data architectures that feed data lakes and streaming pipelines.

What remains open

The source is the announcement from a specific commercial fork, focused on its Enterprise edition. What the Brazilian infrastructure team needs to confirm on its own: in which upstream PostgreSQL versions each CVE was fixed, whether your distribution (Debian, RHEL, Ubuntu) or your managed provider (RDS, Cloud SQL, Azure Database) has already released the packages, and whether exposed instances or those with extensions such as pg_stat_statements and PL/Perl enabled require priority. Given flaws with potential for RCE and SQL injection, the safe path is to treat the patch as urgent and cross-check the list of CVEs above against your fleet's inventory.