diff --git a/SOURCES/00399-cve-2023-24329.patch b/SOURCES/00399-cve-2023-24329.patch
new file mode 100644
index 0000000..6e01787
--- /dev/null
+++ b/SOURCES/00399-cve-2023-24329.patch
@@ -0,0 +1,229 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: "Miss Islington (bot)"
+ <31488909+miss-islington@users.noreply.github.com>
+Date: Wed, 17 May 2023 14:41:25 -0700
+Subject: [PATCH] 00399: CVE-2023-24329
+
+* gh-102153: Start stripping C0 control and space chars in `urlsplit` (GH-102508)
+
+`urllib.parse.urlsplit` has already been respecting the WHATWG spec a bit GH-25595.
+
+This adds more sanitizing to respect the "Remove any leading C0 control or space from input" [rule](https://url.spec.whatwg.org/GH-url-parsing:~:text=Remove%20any%20leading%20and%20trailing%20C0%20control%20or%20space%20from%20input.) in response to [CVE-2023-24329](https://nvd.nist.gov/vuln/detail/CVE-2023-24329).
+
+---------
+
+(cherry picked from commit 2f630e1ce18ad2e07428296532a68b11dc66ad10)
+
+Co-authored-by: Illia Volochii <illia.volochii@gmail.com>
+Co-authored-by: Gregory P. Smith [Google] <greg@krypto.org>
+---
+ Doc/library/urllib.parse.rst                  | 46 +++++++++++++-
+ Lib/test/test_urlparse.py                     | 61 ++++++++++++++++++-
+ Lib/urllib/parse.py                           | 12 ++++
+ ...-03-07-20-59-17.gh-issue-102153.14CLSZ.rst |  3 +
+ 4 files changed, 119 insertions(+), 3 deletions(-)
+ create mode 100644 Misc/NEWS.d/next/Security/2023-03-07-20-59-17.gh-issue-102153.14CLSZ.rst
+
+diff --git a/Doc/library/urllib.parse.rst b/Doc/library/urllib.parse.rst
+index f0f8605128..c76b5879ea 100644
+--- a/Doc/library/urllib.parse.rst
++++ b/Doc/library/urllib.parse.rst
+@@ -159,6 +159,10 @@ or on combining URL components into a URL string.
+       ParseResult(scheme='http', netloc='www.cwi.nl:80', path='/%7Eguido/Python.html',
+                   params='', query='', fragment='')
+ 
++   .. warning::
++
++      :func:`urlparse` does not perform validation.  See :ref:`URL parsing
++      security <url-parsing-security>` for details.
+ 
+    .. versionchanged:: 3.2
+       Added IPv6 URL parsing capabilities.
+@@ -323,8 +327,14 @@ or on combining URL components into a URL string.
+    ``#``, ``@``, or ``:`` will raise a :exc:`ValueError`. If the URL is
+    decomposed before parsing, no error will be raised.
+ 
+-   Following the `WHATWG spec`_ that updates RFC 3986, ASCII newline
+-   ``\n``, ``\r`` and tab ``\t`` characters are stripped from the URL.
++   Following some of the `WHATWG spec`_ that updates RFC 3986, leading C0
++   control and space characters are stripped from the URL. ``\n``,
++   ``\r`` and tab ``\t`` characters are removed from the URL at any position.
++
++   .. warning::
++
++      :func:`urlsplit` does not perform validation.  See :ref:`URL parsing
++      security <url-parsing-security>` for details.
+ 
+    .. versionchanged:: 3.6
+       Out-of-range port numbers now raise :exc:`ValueError`, instead of
+@@ -337,6 +347,9 @@ or on combining URL components into a URL string.
+    .. versionchanged:: 3.9.5
+       ASCII newline and tab characters are stripped from the URL.
+ 
++   .. versionchanged:: 3.9.17
++      Leading WHATWG C0 control and space characters are stripped from the URL.
++
+ .. _WHATWG spec: https://url.spec.whatwg.org/#concept-basic-url-parser
+ 
+ .. function:: urlunsplit(parts)
+@@ -413,6 +426,35 @@ or on combining URL components into a URL string.
+    or ``scheme://host/path``). If *url* is not a wrapped URL, it is returned
+    without changes.
+ 
++.. _url-parsing-security:
++
++URL parsing security
++--------------------
++
++The :func:`urlsplit` and :func:`urlparse` APIs do not perform **validation** of
++inputs.  They may not raise errors on inputs that other applications consider
++invalid.  They may also succeed on some inputs that might not be considered
++URLs elsewhere.  Their purpose is for practical functionality rather than
++purity.
++
++Instead of raising an exception on unusual input, they may instead return some
++component parts as empty strings. Or components may contain more than perhaps
++they should.
++
++We recommend that users of these APIs where the values may be used anywhere
++with security implications code defensively. Do some verification within your
++code before trusting a returned component part.  Does that ``scheme`` make
++sense?  Is that a sensible ``path``?  Is there anything strange about that
++``hostname``?  etc.
++
++What constitutes a URL is not universally well defined.  Different applications
++have different needs and desired constraints.  For instance the living `WHATWG
++spec`_ describes what user facing web clients such as a web browser require.
++While :rfc:`3986` is more general.  These functions incorporate some aspects of
++both, but cannot be claimed compliant with either.  The APIs and existing user
++code with expectations on specific behaviors predate both standards leading us
++to be very cautious about making API behavior changes.
++
+ .. _parsing-ascii-encoded-bytes:
+ 
+ Parsing ASCII Encoded Bytes
+diff --git a/Lib/test/test_urlparse.py b/Lib/test/test_urlparse.py
+index 31943f357f..574da5bd69 100644
+--- a/Lib/test/test_urlparse.py
++++ b/Lib/test/test_urlparse.py
+@@ -649,6 +649,65 @@ class UrlParseTestCase(unittest.TestCase):
+             self.assertEqual(p.scheme, "http")
+             self.assertEqual(p.geturl(), "http://www.python.org/javascript:alert('msg')/?query=something#fragment")
+ 
++    def test_urlsplit_strip_url(self):
++        noise = bytes(range(0, 0x20 + 1))
++        base_url = "http://User:Pass@www.python.org:080/doc/?query=yes#frag"
++
++        url = noise.decode("utf-8") + base_url
++        p = urllib.parse.urlsplit(url)
++        self.assertEqual(p.scheme, "http")
++        self.assertEqual(p.netloc, "User:Pass@www.python.org:080")
++        self.assertEqual(p.path, "/doc/")
++        self.assertEqual(p.query, "query=yes")
++        self.assertEqual(p.fragment, "frag")
++        self.assertEqual(p.username, "User")
++        self.assertEqual(p.password, "Pass")
++        self.assertEqual(p.hostname, "www.python.org")
++        self.assertEqual(p.port, 80)
++        self.assertEqual(p.geturl(), base_url)
++
++        url = noise + base_url.encode("utf-8")
++        p = urllib.parse.urlsplit(url)
++        self.assertEqual(p.scheme, b"http")
++        self.assertEqual(p.netloc, b"User:Pass@www.python.org:080")
++        self.assertEqual(p.path, b"/doc/")
++        self.assertEqual(p.query, b"query=yes")
++        self.assertEqual(p.fragment, b"frag")
++        self.assertEqual(p.username, b"User")
++        self.assertEqual(p.password, b"Pass")
++        self.assertEqual(p.hostname, b"www.python.org")
++        self.assertEqual(p.port, 80)
++        self.assertEqual(p.geturl(), base_url.encode("utf-8"))
++
++        # Test that trailing space is preserved as some applications rely on
++        # this within query strings.
++        query_spaces_url = "https://www.python.org:88/doc/?query=    "
++        p = urllib.parse.urlsplit(noise.decode("utf-8") + query_spaces_url)
++        self.assertEqual(p.scheme, "https")
++        self.assertEqual(p.netloc, "www.python.org:88")
++        self.assertEqual(p.path, "/doc/")
++        self.assertEqual(p.query, "query=    ")
++        self.assertEqual(p.port, 88)
++        self.assertEqual(p.geturl(), query_spaces_url)
++
++        p = urllib.parse.urlsplit("www.pypi.org ")
++        # That "hostname" gets considered a "path" due to the
++        # trailing space and our existing logic...  YUCK...
++        # and re-assembles via geturl aka unurlsplit into the original.
++        # django.core.validators.URLValidator (at least through v3.2) relies on
++        # this, for better or worse, to catch it in a ValidationError via its
++        # regular expressions.
++        # Here we test the basic round trip concept of such a trailing space.
++        self.assertEqual(urllib.parse.urlunsplit(p), "www.pypi.org ")
++
++        # with scheme as cache-key
++        url = "//www.python.org/"
++        scheme = noise.decode("utf-8") + "https" + noise.decode("utf-8")
++        for _ in range(2):
++            p = urllib.parse.urlsplit(url, scheme=scheme)
++            self.assertEqual(p.scheme, "https")
++            self.assertEqual(p.geturl(), "https://www.python.org/")
++
+     def test_attributes_bad_port(self):
+         """Check handling of invalid ports."""
+         for bytes in (False, True):
+@@ -656,7 +715,7 @@ class UrlParseTestCase(unittest.TestCase):
+                 for port in ("foo", "1.5", "-1", "0x10"):
+                     with self.subTest(bytes=bytes, parse=parse, port=port):
+                         netloc = "www.example.net:" + port
+-                        url = "http://" + netloc
++                        url = "http://" + netloc + "/"
+                         if bytes:
+                             netloc = netloc.encode("ascii")
+                             url = url.encode("ascii")
+diff --git a/Lib/urllib/parse.py b/Lib/urllib/parse.py
+index b7965fe3d2..5b7193f67c 100644
+--- a/Lib/urllib/parse.py
++++ b/Lib/urllib/parse.py
+@@ -25,6 +25,10 @@ currently not entirely compliant with this RFC due to defacto
+ scenarios for parsing, and for backward compatibility purposes, some
+ parsing quirks from older RFCs are retained. The testcases in
+ test_urlparse.py provides a good indicator of parsing behavior.
++
++The WHATWG URL Parser spec should also be considered.  We are not compliant with
++it either due to existing user code API behavior expectations (Hyrum's Law).
++It serves as a useful guide when making changes.
+ """
+ 
+ import re
+@@ -78,6 +82,10 @@ scheme_chars = ('abcdefghijklmnopqrstuvwxyz'
+                 '0123456789'
+                 '+-.')
+ 
++# Leading and trailing C0 control and space to be stripped per WHATWG spec.
++# == "".join([chr(i) for i in range(0, 0x20 + 1)])
++_WHATWG_C0_CONTROL_OR_SPACE = '\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f '
++
+ # Unsafe bytes to be removed per WHATWG spec
+ _UNSAFE_URL_BYTES_TO_REMOVE = ['\t', '\r', '\n']
+ 
+@@ -456,6 +464,10 @@ def urlsplit(url, scheme='', allow_fragments=True):
+     """
+ 
+     url, scheme, _coerce_result = _coerce_args(url, scheme)
++    # Only lstrip url as some applications rely on preserving trailing space.
++    # (https://url.spec.whatwg.org/#concept-basic-url-parser would strip both)
++    url = url.lstrip(_WHATWG_C0_CONTROL_OR_SPACE)
++    scheme = scheme.strip(_WHATWG_C0_CONTROL_OR_SPACE)
+ 
+     for b in _UNSAFE_URL_BYTES_TO_REMOVE:
+         url = url.replace(b, "")
+diff --git a/Misc/NEWS.d/next/Security/2023-03-07-20-59-17.gh-issue-102153.14CLSZ.rst b/Misc/NEWS.d/next/Security/2023-03-07-20-59-17.gh-issue-102153.14CLSZ.rst
+new file mode 100644
+index 0000000000..e57ac4ed3a
+--- /dev/null
++++ b/Misc/NEWS.d/next/Security/2023-03-07-20-59-17.gh-issue-102153.14CLSZ.rst
+@@ -0,0 +1,3 @@
++:func:`urllib.parse.urlsplit` now strips leading C0 control and space
++characters following the specification for URLs defined by WHATWG in
++response to CVE-2023-24329. Patch by Illia Volochii.
diff --git a/SPECS/python3.9.spec b/SPECS/python3.9.spec
index 11e614c..3636b02 100644
--- a/SPECS/python3.9.spec
+++ b/SPECS/python3.9.spec
@@ -17,7 +17,7 @@ URL: https://www.python.org/
 #global prerel ...
 %global upstream_version %{general_version}%{?prerel}
 Version: %{general_version}%{?prerel:~%{prerel}}
-Release: 1%{?dist}
+Release: 1%{?dist}.1
 License: Python
 
 
@@ -399,6 +399,18 @@ Patch329: 00329-fips.patch
 # a nightmare because it's basically a binary file.
 Patch353: 00353-architecture-names-upstream-downstream.patch
 
+# 00399 # c32eff86eb80f6a6bdcbf4b1b6535fbc627b51a2
+# CVE-2023-24329
+#
+# * gh-102153: Start stripping C0 control and space chars in `urlsplit` (GH-102508)
+#
+# `urllib.parse.urlsplit` has already been respecting the WHATWG spec a bit GH-25595.
+#
+# This adds more sanitizing to respect the "Remove any leading C0 control or space from input" [rule](https://url.spec.whatwg.org/GH-url-parsing:~:text=Remove%%20any%%20leading%%20and%%20trailing%%20C0%%20control%%20or%%20space%%20from%%20input.) in response to [CVE-2023-24329](https://nvd.nist.gov/vuln/detail/CVE-2023-24329).
+#
+# ---------
+Patch399: 00399-cve-2023-24329.patch
+
 # (New patches go here ^^^)
 #
 # When adding new patches to "python" and "python3" in Fedora, EL, etc.,
@@ -1800,6 +1812,10 @@ CheckPython optimized
 # ======================================================
 
 %changelog
+* Mon May 29 2023 Charalampos Stratakis <cstratak@redhat.com> - 3.9.16-1.1
+- Security fix for CVE-2023-24329
+Resolves: rhbz#2173917
+
 * Wed Mar 15 2023 MSVSphere Packaging Team <packager@msvsphere.ru> - 3.9.14-1
 - Rebuilt for MSVSphere 9.1.