ZLLentz
commented
11 months ago Ok, actually, I don't like this at all. I should have stuck with the 5.8.0 plan. The security vulnerability list here is a mile long.
aiohttp 3.7.4.post0 PYSEC-2023-120 aiohttp.web.Application vulnerable to HTTP request smuggling via llhttp HTTP request parser
cryptography 39.0.0 GHSA-5cpq-8wj7-hf2v 41.0.0 Vulnerable OpenSSL included in cryptography wheels
cryptography 39.0.0 GHSA-jm77-qphf-c4w8 41.0.3 pyca/cryptography's wheels include vulnerable OpenSSL
cryptography 39.0.0 GHSA-v8gr-m533-ghj9 41.0.4 Vulnerable OpenSSL included in cryptography wheels
cryptography 39.0.0 GHSA-w7pp-m8wf-vj6r 39.0.1 Cipher.update_into can corrupt memory if passed an immutable python object as the outbuf
cryptography 39.0.0 GHSA-x4qr-2fvf-3mr5 39.0.1 Vulnerable OpenSSL included in cryptography wheels
gitpython 3.1.31 PYSEC-2023-137 3.1.32 GitPython before 3.1.32 does not block insecure non-multi options in clone and clone_from. NOTE: this issue exists because of an incomplete fix for CVE-2022-24439.
gitpython 3.1.31 PYSEC-2023-161 3.1.33 GitPython is a python library used to interact with Git repositories. When resolving a program, Python/Windows look for the current working directory, and after that the PATH environment. GitPython defaults to use the `git` command, if a user runs GitPython from a repo has a `git.exe` or `git` executable, that program will be run instead of the one in the user's `PATH`. This is more of a problem on how Python interacts with Windows systems, Linux and any other OS aren't affected by this. But probably people using GitPython usually run it from the CWD of a repo. An attacker can trick a user to download a repository with a malicious `git` executable, if the user runs/imports GitPython from that directory, it allows the attacker to run any arbitrary commands. There is no fix currently available for windows users, however there are a few mitigations. 1: Default to an absolute path for the git program on Windows, like `C:\\Program Files\\Git\\cmd\\git.EXE` (default git path installation). 2: Require users to set the `GIT_PYTHON_GIT_EXECUTABLE` environment variable on Windows systems. 3: Make this problem prominent in the documentation and advise users to never run GitPython from an untrusted repo, or set the `GIT_PYTHON_GIT_EXECUTABLE` env var to an absolute path. 4: Resolve the executable manually by only looking into the `PATH` environment variable.
gitpython 3.1.31 PYSEC-2023-165 3.1.35 GitPython is a python library used to interact with Git repositories. In order to resolve some git references, GitPython reads files from the `.git` directory, in some places the name of the file being read is provided by the user, GitPython doesn't check if this file is located outside the `.git` directory. This allows an attacker to make GitPython read any file from the system. This vulnerability is present in https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/refs/symbolic.py#L174-L175. That code joins the base directory with a user given string without checking if the final path is located outside the base directory. This vulnerability cannot be used to read the contents of files but could in theory be used to trigger a denial of service for the program. This issue has not yet been addressed.
grpcio 1.51.1 GHSA-6628-q6j9-w8vg 1.53.0 gRPC Reachable Assertion issue
grpcio 1.51.1 GHSA-9hxf-ppjv-w6rq 1.53.0 gRPC connection termination issue
grpcio 1.51.1 GHSA-cfgp-2977-2fmm 1.53.0 Connection confusion in gRPC
imagecodecs 2021.3.31 PYSEC-2023-174 2023.9.18 imagecodecs versions before v2023.9.18 bundled libwebp binaries in wheels that are vulnerable to CVE-2023-5129 (previously CVE-2023-4863). imagecodecs v2023.9.18 upgrades the bundled libwebp binary to v1.3.2.
imagecodecs 2021.3.31 GHSA-94vc-p8w7-5p49 2023.9.18 Bundled libwebp in imagecodecs vulnerable
ipython 8.4.0 GHSA-29gw-9793-fvw7 8.10 IPython vulnerable to command injection via set_term_title
jupyter-server 1.23.6 PYSEC-2023-155 2.7.2 jupyter-server is the backend for Jupyter web applications. Open Redirect Vulnerability. Maliciously crafted login links to known Jupyter Servers can cause successful login or an already logged-in session to be redirected to arbitrary sites, which should be restricted to Jupyter Server-served URLs. This issue has been addressed in commit `29036259` which is included in release 2.7.2. Users are advised to upgrade. There are no known workarounds for this vulnerability.
jupyter-server 1.23.6 PYSEC-2023-157 2.7.2 jupyter-server is the backend for Jupyter web applications. Improper cross-site credential checks on `/files/` URLs could allow exposure of certain file contents, or accessing files when opening untrusted files via "Open image in new tab". This issue has been addressed in commit `87a49272728` which has been included in release `2.7.2`. Users are advised to upgrade. Users unable to upgrade may use the lower performance `--ContentsManager.files_handler_class=jupyter_server.files.handlers.FilesHandler`, which implements the correct checks.
lxml 4.8.0 PYSEC-2022-230 4.9.1 NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.
numexpr 2.7.3 PYSEC-2023-163 An issue in LanChain-ai Langchain v.0.0.245 allows a remote attacker to execute arbitrary code via the evaluate function in the numexpr library.
pillow 9.5.0 PYSEC-2023-175 10.0.1 Pillow versions before v10.0.1 bundled libwebp binaries in wheels that are vulnerable to CVE-2023-5129 (previously CVE-2023-4863). Pillow v10.0.1 upgrades the bundled libwebp binary to v1.3.2.
pillow 9.5.0 GHSA-56pw-mpj4-fxww 10.0.1 Bundled libwebp in Pillow vulnerable
pillow 9.5.0 GHSA-j7hp-h8jx-5ppr 10.0.1 libwebp: OOB write in BuildHuffmanTable
pygments 2.15.0 PYSEC-2023-117 2.15.1 A ReDoS issue was discovered in pygments/lexers/smithy.py in pygments through 2.15.0 via SmithyLexer.
reportlab 3.5.68 GHSA-9q9m-c65c-37pq 3.6.13 Reportlab vulnerable to remote code execution
requests 2.28.2 PYSEC-2023-74 2.31.0 Requests is a HTTP library. Since Requests 2.3.0, Requests has been leaking Proxy-Authorization headers to destination servers when redirected to an HTTPS endpoint. This is a product of how we use `rebuild_proxies` to reattach the `Proxy-Authorization` header to requests. For HTTP connections sent through the tunnel, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the `Proxy-Authorization` header must be sent in the CONNECT request as the proxy has no visibility into the tunneled request. This results in Requests forwarding proxy credentials to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate sensitive information. This issue has been patched in version 2.31.0.
starlette 0.26.1 PYSEC-2023-83 0.27.0 Directory traversal vulnerability in Starlette versions 0.13.5 and later and prior to 0.27.0 allows a remote unauthenticated attacker to view files in a web service which was built using Starlette.
tornado 6.2 PYSEC-2023-75 6.3.2 Open redirect vulnerability in Tornado versions 6.3.1 and earlier allows a remote unauthenticated attacker to redirect a user to an arbitrary web site and conduct a phishing attack by having user access a specially crafted URL.
tornado 6.2 GHSA-qppv-j76h-2rpx 6.3.3 Tornado vulnerable to HTTP request smuggling via improper parsing of `Content-Length` fields and chunk lengths
urllib3 1.26.15 GHSA-v845-jxx5-vc9f 1.26.17 `Cookie` HTTP header isn't stripped on cross-origin redirects
WIP, probably, unless all the CI somehow passes
need to add the closes lines I also want to tackle one of the deploy issues