An issue in the urllib.parse component of Python before 3.11.4 allows attackers to bypass blocklisting methods by supplying a URL that starts with blank characters.
Everyone (including the [submitter](https://pointernull.com/security/python-url-parse-problem.html) of the now public exploit who submitted the issue half a year ago to `security@python.org` and the [NVD](https://nvd.nist.gov/vuln/detail/CVE-2023-24329)) seems to think that #99421 "accidently fixed" CVE-2023-24329.

Did the Python Security Response Team verify that this vulnerability that was reported to them and that is now public was fixed by #99421?

The PoC from the submitter still works for me with the Debian package 3.11.2-4, which surprised me and makes me wonder whether the fix had any effect at all on the stripping of leading blanks issue in the CVE.

<!-- gh-linked-prs -->
### Linked PRs
* gh-102470
* gh-102508
* gh-104575
* gh-104592
* gh-104593
* gh-104895
* gh-104896
* gh-104918
<!-- /gh-linked-prs -->

urllib.parse space handling CVE-2023-24329 appears unfixed
This is a GitHub Issue
repo:cpython
owner:python
Title : urllib.parse space handling CVE-2023-24329 appears unfixed
Issue date:

--- start body ---
Everyone (including the [submitter](https://pointernull.com/security/python-url-parse-problem.html) of the now public exploit who submitted the issue half a year ago to `security@python.org` and the [NVD](https://nvd.nist.gov/vuln/detail/CVE-2023-24329)) seems to think that #99421 "accidently fixed" CVE-2023-24329.

Did the Python Security Response Team verify that this vulnerability that was reported to them and that is now public was fixed by #99421?

The PoC from the submitter still works for me with the Debian package 3.11.2-4, which surprised me and makes me wonder whether the fix had any effect at all on the stripping of leading blanks issue in the CVE.

<!-- gh-linked-prs -->
### Linked PRs
* gh-102470
* gh-102508
* gh-104575
* gh-104592
* gh-104593
* gh-104895
* gh-104896
* gh-104918
<!-- /gh-linked-prs -->

--- end body ---
