In T273020#7271039, @sbassett wrote:

Security Review Summary - T273020 - 2021-08-09
Last commit reviewed: d9e475d1ff13

[...snip...]

Vulnerable Packages - Production - python

The following vulnerabilities were found for installed packages via python's safety db. Risk: Medium.

Package	Affected Version(s)	Installed Version	Vulnerability
cryptography	<3.3	3.2.1	Cryptography 3.3 no longer allows loading of finite field Diffie-Hellman parameters of less than 512 bits in length. This change is to conform with an upcoming OpenSSL release that no longer supports smaller sizes. These keys were already wildly insecure and should not have been used in any application outside of testing.
cryptography	<3.3.2	3.2.1	In the cryptography package before 3.3.2 for Python, certain sequences of update calls to symmetrically encrypt multi-GB values could result in an integer overflow and buffer overflow, as demonstrated by the Fernet class. See: CVE-2020-36242.
django	==2.2.17	2.2.17	Django 2.2.18 fixes a security issue with severity "low" in 2.2.17 (CVE-2021-3281).
django	>=2.0.0a1,<2.2.24	2.2.17	Django 2.2.24, 3.1.12, and 3.2.4 includes a fix for CVE-2021-33203: Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories.
django	>=2.2,<2.2.18	2.2.17	In Django 2.2 before 2.2.18, 3.0 before 3.0.12, and 3.1 before 3.1.6, the django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments. See CVE-2021-3281.
django	>=2.2,<2.2.21	2.2.17	In Django 2.2 before 2.2.21, 3.1 before 3.1.9, and 3.2 before 3.2.1, MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names.
django	>=2.2.0a1,<2.2.24	2.2.17	Django 2.2.24, 3.1.12, and 3.2.4 includes a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+).
django	>=2.2a1,<2.2.20	2.2.17	In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	>=2.2a1,<2.2.22	2.2.17	In Django 2.2 before 2.2.22, 3.1 before 3.1.10, and 3.2 before 3.2.2 (with Python 3.9.5+), URLValidator does not prohibit newlines and tabs (unless the URLField form field is used). If an application uses values with newlines in an HTTP response, header injection can occur. Django itself is unaffected because HttpResponse prohibits newlines in HTTP headers.
pyyaml	<5.4	5.3.1	A vulnerability was discovered in the PyYAML library in versions before 5.4, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. This flaw allows an attacker to execute arbitrary code on the system by abusing the python/object/new constructor. This flaw is due to an incomplete fix for CVE-2020-1747.
urllib3	>=1.26.0,<1.26.4	1.26.2	Urllib3 1.26.4 includes a fix for CVE-2021-28363: The urllib3 library 1.26.x before 1.26.4 for Python omits SSL certificate validation in some cases involving HTTPS to HTTPS proxies. The initial connection to the HTTPS proxy (if an SSLContext isn't given via proxy_config) doesn't verify the hostname of the certificate. This means certificates for different servers that still validate properly with the default urllib3 SSLContext will be silently accepted.