From 6060af5ba304f32ae79b0823589c461365812a4e Mon Sep 17 00:00:00 2001
From: Yogesh Sharma <yogesh.sharma@catprosystems.com>
Date: Wed, 2 Sep 2026 00:47:28 -0400
Subject: [PATCH v1] PG14 following CVEs were not back patched. Remove
 CVE-2026-16238, CVE-2026-14681, CVE-2026-14672, and CVE-2026-14676.

---
 doc/src/sgml/release-14.sgml | 115 -----------------------------------
 1 file changed, 115 deletions(-)

diff --git a/doc/src/sgml/release-14.sgml b/doc/src/sgml/release-14.sgml
index a5c72b82592..df6ca90c1a8 100644
--- a/doc/src/sgml/release-14.sgml
+++ b/doc/src/sgml/release-14.sgml
@@ -360,35 +360,6 @@ Branch: REL_14_STABLE [42d333a78] 2026-08-10 06:38:36 -0700
 
     <listitem>
 <!--
-Author: Michael Paquier <michael@paquier.xyz>
-Branch: master [57835938f] 2026-08-10 06:37:49 -0700
-Branch: REL_19_STABLE [b3d9262bb] 2026-08-10 06:38:05 -0700
-Branch: REL_18_STABLE [08454e8b2] 2026-08-10 06:38:12 -0700
-Branch: REL_18_STABLE [8d428c6e6] 2026-08-10 06:38:12 -0700
--->
-     <para>
-      Fix multirange type handling
-      in <function>pg_restore_attribute_stats()</function>
-      (OpenAI Security Research Team)
-     </para>
-
-     <para>
-      <function>pg_restore_attribute_stats()</function> treated multirange
-      types just like their underlying range type.  This works correctly
-      for the bounds histogram, but it was wrong for all the other
-      statistics kinds.
-     </para>
-
-     <para>
-      The <productname>PostgreSQL</productname> Project thanks
-      Amy Burnett (OpenAI Codex Security)
-      for reporting this problem.
-      (CVE-2026-16238)
-     </para>
-    </listitem>
-
-    <listitem>
-<!--
 Author: Tom Lane <tgl@sss.pgh.pa.us>
 Branch: master [8f0c3d2fe] 2026-08-10 06:37:48 -0700
 Branch: REL_19_STABLE [0d60ee717] 2026-08-10 06:38:04 -0700
@@ -682,67 +653,6 @@ Branch: REL_14_STABLE [f4174aa84] 2026-08-10 06:38:36 -0700
     <listitem>
 <!--
 Author: Michael Paquier <michael@paquier.xyz>
-Branch: master [3bf185b4b] 2026-08-10 06:37:49 -0700
-Branch: REL_19_STABLE [bf1bb7e29] 2026-08-10 06:38:05 -0700
-Branch: REL_18_STABLE [203a48209] 2026-08-10 06:38:11 -0700
-Branch: REL_17_STABLE [067a64d40] 2026-08-10 06:38:18 -0700
--->
-     <para>
-      Reject GSSEncRequest after direct SSL connection (Michael Paquier)
-     </para>
-
-     <para>
-      After establishing a TLS-encrypted connection, the server would
-      still accept a request for GSSAPI encryption.  If that succeeded,
-      the connection would proceed using TLS encryption, but it would look
-      like a GSS connection to the <filename>pg_hba</filename> rules.
-      Thus, a <filename>pg_hba</filename> policy intending to disallow TLS
-      would not be enforced correctly.
-     </para>
-
-     <para>
-      The <productname>PostgreSQL</productname> Project thanks
-      p4p3r
-      for reporting this problem.
-      (CVE-2026-14681)
-     </para>
-    </listitem>
-
-    <listitem>
-<!--
-Author: Nathan Bossart <nathan@postgresql.org>
-Branch: master [feb8b0182] 2026-08-10 06:37:49 -0700
-Branch: REL_19_STABLE [4d192fa16] 2026-08-10 06:38:05 -0700
-Branch: REL_18_STABLE [822143c4d] 2026-08-10 06:38:12 -0700
-Branch: REL_17_STABLE [dec60e8ad] 2026-08-10 06:38:18 -0700
-Branch: REL_16_STABLE [fadbe882d] 2026-08-10 06:38:24 -0700
--->
-     <para>
-      Make mock SCRAM authentication secrets more plausible (Nathan Bossart)
-     </para>
-
-     <para>
-      If a SCRAM login is attempted against a role that doesn't exist or
-      doesn't have a SCRAM secret, we generate a mock secret and carry out
-      the authentication handshake anyway, to avoid revealing these facts
-      to an attacker.  But the mock secret was made with a fixed iteration
-      count, which in itself can be an observable response discrepancy.
-      Use the configuration setting <varname>scram_iterations</varname>
-      instead, to make the mock secret look more like the installation's
-      real secrets.
-     </para>
-
-     <para>
-      The <productname>PostgreSQL</productname> Project thanks
-      Radim Marek
-      for reporting this problem.
-      (CVE-2026-14672)
-     </para>
-    </listitem>
-
-    <listitem>
-<!--
-Author: Michael Paquier <michael@paquier.xyz>
 Branch: master [c7da85fec] 2026-08-10 06:37:49 -0700
 Branch: REL_19_STABLE [457b8737a] 2026-08-10 06:38:05 -0700
 Branch: REL_18_STABLE [a14ba29b1] 2026-08-10 06:38:11 -0700
@@ -978,31 +888,6 @@ Branch: REL_14_STABLE [9505175f2] 2026-08-10 06:38:36 -0700
 
     <listitem>
 <!--
-Author: Álvaro Herrera <alvherre@kurilemu.de>
-Branch: master [1e2795dde] 2026-08-10 06:37:48 -0700
-Branch: REL_19_STABLE [bb02eba53] 2026-08-10 06:38:04 -0700
-Branch: REL_18_STABLE [8a31ffc2d] 2026-08-10 06:38:11 -0700
--->
-     <para>
-      Fix buffer overrun
-      in <filename>contrib/pg_stat_statements</filename> (Álvaro Herrera)
-     </para>
-
-     <para>
-      Query normalization didn't accurately account for the amount of
-      space the normalized string would require.
-     </para>
-
-     <para>
-      The <productname>PostgreSQL</productname> Project thanks
-      Sajeeb Lohani (with TrendAI Zero Day Initiative) and Yuelin Wang
-      for reporting this problem.
-      (CVE-2026-14676)
-     </para>
-    </listitem>
-
-    <listitem>
-<!--
 Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
 Branch: master [66c2dbb20] 2026-08-10 06:37:48 -0700
 Branch: REL_19_STABLE [aa7b5815e] 2026-08-10 06:38:04 -0700
-- 
2.55.0

