On August 13, 2026, the PostgreSQL Global Development Group shipped an update to every supported branch—18.6, 17.11, 16.15, 15.19, and 14.24—alongside PostgreSQL 19 Beta 3. The headline number: 28 security vulnerabilities closed and over 110 bugs fixed. If you run PostgreSQL on Amazon RDS, the obvious follow-up question is: my fleet is still on 18.4—when do I actually get these fixes?
Here’s what shipped, why several of the CVEs are serious, and a realistic read on the Amazon RDS timeline.
Table of Contents
What “28 security issues” actually means
Most of this batch isn’t theoretical. A large share are arbitrary-code-execution bugs rated CVSS 8.8, reachable by any authenticated user with a normal SQL connection (AV:N/AC:L/PR:L/UI:N … C:H/I:H/A:H). That combination—low privileges required, no user interaction, full confidentiality/integrity/ availability impact—is exactly the profile that turns a shared multi-tenant database into a lateral-movement risk.
A selection of the higher-impact fixes:
| CVE | Component | CVSS | Summary |
|---|---|---|---|
| CVE-2026-14664 | core server | 8.8 | Regexp heap buffer overflow → arbitrary code execution |
| CVE-2026-14669 | core server | 8.8 | to_char heap buffer overflow → arbitrary code execution |
| CVE-2026-14670 | core server | 8.8 | plperl tied-object heap buffer overflow → arbitrary code execution |
| CVE-2026-14671 | contrib (refint) | 8.8 | Plan-cache type confusion → arbitrary code execution |
| CVE-2026-14676 | contrib (pg_stat_statements) | 8.8 | Heap buffer overflow → arbitrary code execution |
| CVE-2026-14680 | core server | 8.8 | Type confusion via internal arguments |
| CVE-2026-14662 | core server | 8.8 | tsvector/tsquery undersized allocations via integer wraparound |
| CVE-2026-15741 | core server | 8.8 | Expression deparse allows SQL injection via EXTRACT argument |
| CVE-2026-15742 | contrib (fuzzystrmatch) | 8.8 | Writes effectively-arbitrary addresses via integer wraparound |
| CVE-2026-16238 | core server | 8.8 | Type confusion in pg_restore_attribute_stats() → arbitrary code |
| CVE-2026-16239 | core server | 8.8 | Type confusion in cursor CLOSE + DECLARE → arbitrary code |
| CVE-2026-19385 | client (pg_dump) | 8.8 | pg_dump heap buffer overflow → arbitrary code execution |
| CVE-2026-18408 | client (psql) | 8.8 | psql \unrestrict lets a malicious dump origin run code in the client |
| CVE-2026-6464 | client (psql) | 8.1 | COPY FROM STDIN early failure processes data lines as psql commands |
| CVE-2026-6471 | core server | 7.2 | Logical decoding can dlopen an arbitrary file |
The full 28 also include lower-severity information-disclosure and privilege-check issues (e.g. CVE-2026-14663 pgcrypto silently encrypting to/from cleartext for OpenSSL-disabled ciphers, CVE-2026-14672 a SCRAM user-existence oracle, CVE-2026-14666 row-security caching ignoring role changes, and CVE-2026-6470 a missing type USAGE privilege check).
Two takeaways for RDS operators:
- Client-side CVEs matter even if the server is patched.
pg_dump,psql, andpg_createsubscriberbugs (CVE-2026-19385, CVE-2026-18408, CVE-2026-6464) are exploited through your tooling. Update your localpostgresql-clientpackages and any bastion/CI images regardless of when RDS moves. SET/ low-privilege reachability means “we trust our app user” is not a mitigation. Any account that can run SQL can reach several of these paths.
Scheduling note: the community originally planned 18.5, but it was pulled due to a regression and never shipped—18.6 is the release that carries these fixes. If you see a CVE table listing “18.5,” read it as “18.6” for the PostgreSQL 18 branch.
A few bug fixes that need post-upgrade action
Independent of the CVEs, three fixes in 18.6 can require manual remediation after you upgrade—worth planning for now so it isn’t a surprise on RDS:
- Parallel GIN index builds could leave
reltuplesset to a bogus value (Infinity/NaN), which silently stops autovacuum/autoanalyze on the table. RunANALYZEon affected tables after upgrading. btree_gistonfloat4/float8(NaN) andbit/bit varyingcolumns may need aREINDEX.ltreebtree indexes with very many labels (>~14,653) may be corrupt and need reindexing.
There’s also a notable non-18 fix highlighted for its severity: a WAL-replay self-deadlock affecting standbys on PostgreSQL 14/15/16 following a primary on an older minor version.
Where Amazon RDS stands today
As of this writing, the newest Amazon RDS for PostgreSQL 18 minor version is 18.4. Community 18.5 (pulled) and 18.6 have not yet landed on RDS. PostgreSQL 19 Beta 3 exists only in the RDS Preview environment and is not for production.
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
So the fixes above are, for now, ahead of what RDS offers on the 18 branch.
When will RDS ship 18.6?
Amazon doesn’t pre-announce exact per-minor-version dates, but the historical pattern is consistent enough to plan around:
- RDS delivers community security fixes through its own minor-version updates. It typically trails an upstream PostgreSQL minor release by roughly a few weeks to about two months, because AWS rebuilds the engine, revalidates its large catalog of managed extensions (PostGIS,
pgvector,pgaudit,pgactive,plv8, etc.), and stages a phased rollout across Regions. - Expect an “-R” revision. RDS frequently publishes a follow-up build (e.g.
18.6-R2) that bundles extension-level security fixes on top of the community engine. If any of your extensions carry their own advisories, the-R2is the one to watch. - PostgreSQL 14 EOL is approaching. Community support for PostgreSQL 14 ends November 12, 2026. If you’re on RDS 14.x, fold “get onto a supported major version” into the same planning cycle.
Given the August 13, 2026 upstream release, a reasonable expectation is RDS availability of the 18.6-equivalent engine in roughly the September–October 2026 window—but treat that as an estimate, not a commitment. Confirm against the authoritative source below.
What to do while you wait
- Check your current engine version and whether auto minor upgrades are on:
SHOW server_version;aws rds describe-db-instances \ --query "DBInstances[].[DBInstanceIdentifier,EngineVersion,AutoMinorVersionUpgrade]" \ --output table - Confirm the target is available in your Region before scheduling:
aws rds describe-db-engine-versions --engine postgres \ --query "DBEngineVersions[?starts_with(EngineVersion,'18.')].EngineVersion" \ --output table - Enable
AutoMinorVersionUpgrade(or plan a maintenance window) so the fix applies as soon as AWS publishes it. Minor upgrades don’t require a dump/reload, but they do cause a brief restart—use Multi-AZ to minimize impact. - Patch your clients now. Update
pg_dump/psql/libpqon laptops, bastions, and CI runners to close the client-side CVEs (CVE-2026-19385, CVE-2026-18408, CVE-2026-6464) independent of the RDS timeline. - Reduce blast radius today. Audit which roles can run arbitrary SQL and which contrib modules (
pg_stat_statements,fuzzystrmatch,pgcrypto,refint,pg_trgm) are actually installed—several CVEs are only reachable if the module is present. - Pre-stage the post-upgrade steps for GIN
reltuples,btree_gist, andltreeso remediation is scripted before the maintenance window.
Bottom line
PostgreSQL 18.6 is a meaningful security release—28 CVEs, many of them low-barrier remote-code-execution paths, plus 110+ bug fixes. Amazon RDS is currently at 18.4 and will pick up the 18.6-equivalent engine on its usual few-weeks-to-two-months cadence, most likely via a minor update (and possibly an -R2 revision). Turn on auto minor upgrades, patch your client tooling now, and watch the RDS release notes for the exact date.
Authoritative sources
- PostgreSQL 18.6 release announcement: https://www.postgresql.org/about/news/postgresql-186-1711-1615-1519-1424-and-19-beta-3-released-3365/
- PostgreSQL security / CVE list: https://www.postgresql.org/support/security/
- Amazon RDS for PostgreSQL release notes: https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html
