Fix errors in 2023-05-11 release

For some reason the last commit dropped the security messaging,
for reasons that are not quite clear.

diff --git a/update_releases/current/20230511securityrelease.md b/update_releases/current/20230511securityrelease.md
index a53ef0dc2e9fd38ea19f41084865289867d60bf1..cfa5c63f60f5d6555fb73e640be9a424fa7dbd5f 100644 (file)
--- a/update_releases/current/20230511securityrelease.md
+++ b/update_releases/current/20230511securityrelease.md
@@ -15,6 +15,39 @@ plans to upgrade to a newer, supported version of PostgreSQL. Please see our
 [versioning policy](https://www.postgresql.org/support/versioning/) for more
 information.
 
+Security Issues
+---------------
+
+### [CVE-2023-2454](https://www.postgresql.org/support/security/CVE-2023-2454/): `CREATE SCHEMA ... schema_element` defeats protective search_path changes.
+
+Versions Affected: 11 - 15. The security team typically does not test
+unsupported versions, but this problem is quite old.
+
+This enabled an attacker having database-level `CREATE` privilege to execute
+arbitrary code as the bootstrap superuser.  Database owners have that right by
+default, and explicit grants may extend it to other users.
+
+The PostgreSQL project thanks Alexander Lakhin for reporting this problem.
+
+### [CVE-2023-2455](https://www.postgresql.org/support/security/CVE-2023-2455/): Row security policies disregard user ID changes after inlining.
+
+Versions Affected: 11 - 15. The security team typically does not test
+unsupported versions, but this problem is quite old.
+
+While [CVE-2016-2193](https://www.postgresql.org/support/security/CVE-2016-2193/)
+fixed most interaction between row security and user ID changes, it missed a
+scenario involving function inlining.  This leads to potentially incorrect
+policies being applied in cases where role-specific policies are used and a
+given query is planned under one role and then executed under other roles.
+This scenario can happen under security definer functions or when a common user
+and query is planned initially and then re-used across multiple SET ROLEs.
+Applying an incorrect policy may permit a user to complete otherwise-forbidden
+reads and modifications. This affects only databases that have used
+[`CREATE POLICY`](https://www.postgresql.org/docs/current/sql-createpolicy.html)
+to define a row security policy.
+
+The PostgreSQL project thanks Wolfgang Walther for reporting this problem.
+
 Bug Fixes and Improvements
 --------------------------