The pgcrypto entry reaches backwards into data already written. pgcrypto asks OpenSSL for a cipher, and OpenSSL can refuse, as it does when it runs in FIPS mode or when the legacy provider has not been loaded [14]. The old code did not check that refusal. It went on to XOR the plaintext with a block that had never been encrypted, which the release notes describe as rendering the encryption trivially breakable [14]. The algorithms that typically land there are the deprecated ones: cipher-algo=blowfish/bf, twofish, cast5 and 3des [15]. Daniel Gustafsson's fix, from a report by Shishir Sharma, adds an ignore-cipher-failure option to pgp_pub_decrypt() and pgp_sym_decrypt() so the faulty wrapper can be stripped off and the data re-encrypted [13][16].
That escape hatch carries a precondition the notes state plainly. OpenSSL has to behave the way it behaved when the faulty messages were created, and if the set of unsupported algorithms is not the same, the approach does not work [17].
Logical decoding gets a narrower fix. The output plugin is a library name the client supplies, and before this release a replication user could select any loadable library, which the project says allowed exploits of various sorts [9]. Jacob Champion's patch bounds the choice to the contents of a new server parameter, output_plugin_libraries [8]. pg_upgrade --check now fails when the new cluster's setting does not permit the plugins of logical replication slots on the old cluster, for migrations from version 17 and later [11]. A pre-flight check that stops on a config line is the friendliest way to find this out.
Three entries in this release carry CVE numbers, and those three are exactly the ones the notes single out as needing configuration adjustment or data cleanup after updating [4][23]. Two of them land in client-side scripts rather than in the server. The psql change closes what the notes call a SQL-injection hazard in the worst case, because in-line data following a COPY that failed at startup was previously read as SQL commands [19]. A fourth entry, from Robert Haas, cross-checks the declared row types of the outer and inner portals used by EXECUTE and FETCH, which could previously be made to diverge, and it is not among the entries flagged for post-update work [22][27].
18.6 collects its fixes from 18.4 because 18.5 was never released, after a regression was discovered post-wrap [2][25].
The summary points at work without describing it. Indexes made with contrib/btree_gist or contrib/ltree may need reindexing [6], hedged with "may", and nothing at the top of the notes says which indexes qualify, nor what a corrupt reltuples value does to plan choice on a GIN-indexed table. Clusters coming from anything earlier than 18.2 get a further pointer, to Section E.4 [7]. The detail lives in the individual changelog entries, and sizing a reindex window takes those entries, not just the summary.
