diff --git a/doc/src/sgml/release-14.sgml b/doc/src/sgml/release-14.sgml
index 34f4b610a83..c4a44b59bc2 100644
--- a/doc/src/sgml/release-14.sgml
+++ b/doc/src/sgml/release-14.sgml
@@ -35,6 +35,102 @@
+
+ Harden PQescapeString and allied functions
+ against invalidly-encoded input strings (Andres Freund, Noah Misch)
+ §
+ §
+ §
+ §
+ §
+ §
+
+
+
+ Data-quoting functions supplied by libpq
+ now fully check the encoding validity of their input. If invalid
+ characters are detected, they report an error if possible. For the
+ ones that lack an error return convention, the output string is
+ adjusted to ensure that the server will report invalid encoding and
+ no intervening processing will be fooled by bytes that might happen
+ to match single quote, backslash, etc.
+
+
+
+ The purpose of this change is to guard against SQL-injection attacks
+ that are possible if one of these functions is used to quote crafted
+ input. There is no hazard when the resulting string is sent
+ directly to a PostgreSQL server (which
+ would check its encoding anyway), but there is a risk when it is
+ passed through psql or other client-side
+ code. Historically such code has not carefully vetted encoding, and
+ in many cases it's not clear what it should do if it did detect such
+ a problem.
+
+
+
+ This fix is effective only if the data-quoting function, the server,
+ and any intermediate processing agree on the character encoding
+ that's being used. Applications that insert untrusted input into
+ SQL commands should take special care to ensure that that's true.
+
+
+
+ Applications and drivers that quote untrusted input without using
+ these libpq functions may be at risk of
+ similar problems. They should first confirm the data is valid in
+ the encoding expected by the server.
+
+
+
+ The PostgreSQL Project thanks
+ Stephen Fewer for reporting this problem.
+ (CVE-2025-1094)
+
+
+
+
+