From 5334b6d8864a5f85bd9df26ce269614c322974bd Mon Sep 17 00:00:00 2001 From: "github.actions" Date: Wed, 15 Nov 2023 08:04:30 +0000 Subject: [PATCH] Latest data: Wed Nov 15 08:04:30 UTC 2023 --- audits/alot-requirements.audit.json | 9 +- audits/ansible-requirements.audit.json | 5 +- audits/athenacli-requirements.audit.json | 12 +- audits/aws-shell-requirements.audit.json | 2 +- audits/awscli-requirements.audit.json | 8 +- audits/bbot-requirements.audit.json | 2 +- audits/breezy-requirements.audit.json | 2 +- audits/buku-requirements.audit.json | 17 +- audits/bzt-requirements.audit.json | 14 +- audits/certbot-requirements.audit.json | 2 +- audits/charm-tools-requirements.audit.json | 21 +- audits/cycode-requirements.audit.json | 7 +- audits/dstack-requirements.audit.json | 2 +- audits/dvc-requirements.audit.json | 2 +- audits/dxpy-requirements.audit.json | 5 +- audits/esphome-requirements.audit.json | 2 +- audits/flintrock-requirements.audit.json | 16 +- audits/gyb-requirements.audit.json | 14 +- audits/howdoi-requirements.audit.json | 2 +- audits/iredis-requirements.audit.json | 2 +- ...enkins-job-builder-requirements.audit.json | 7 +- audits/khal-requirements.audit.json | 2 +- audits/khard-requirements.audit.json | 2 +- audits/litecli-requirements.audit.json | 2 +- audits/literate-git-requirements.audit.json | 24 +- audits/magic-wormhole-requirements.audit.json | 7 +- audits/mvt-requirements.audit.json | 7 +- audits/mycli-requirements.audit.json | 2 +- audits/onlykey-agent-requirements.audit.json | 14 +- audits/pgcli-requirements.audit.json | 2 +- audits/pypy-requirements.audit.json | 39 +- audits/pypy3.10-requirements.audit.json | 28 +- audits/pypy3.9-requirements.audit.json | 28 +- audits/python@3.12-requirements.audit.json | 14 +- audits/recon-ng-requirements.audit.json | 63 +- audits/scoutsuite-requirements.audit.json | 785 ------------------ audits/scrapy-requirements.audit.json | 7 +- audits/sickchill-requirements.audit.json | 2 +- audits/snapcraft-requirements.audit.json | 14 +- audits/terminator-requirements.audit.json | 2 +- audits/tern-requirements.audit.json | 28 +- audits/theharvester-requirements.audit.json | 14 +- audits/torchvision-requirements.audit.json | 7 +- audits/twarc-requirements.audit.json | 2 +- requirements/asitop-requirements.txt | 3 + requirements/aws-sam-cli-requirements.txt | 20 +- requirements/awscli@1-requirements.txt | 2 +- requirements/conan-requirements.txt | 2 +- requirements/conan@1-requirements.txt | 2 +- requirements/dvc-requirements.txt | 16 +- requirements/oci-cli-requirements.txt | 4 +- requirements/pipenv-requirements.txt | 4 + requirements/pwntools-requirements.txt | 4 +- requirements/scoutsuite-requirements.txt | 56 +- requirements/sigma-cli-requirements.txt | 6 +- requirements/thefuck-requirements.txt | 6 +- requirements/yt-dlp-requirements.txt | 6 +- requirements/zurl-requirements.txt | 2 +- 58 files changed, 354 insertions(+), 1027 deletions(-) delete mode 100644 audits/scoutsuite-requirements.audit.json create mode 100644 requirements/asitop-requirements.txt create mode 100644 requirements/pipenv-requirements.txt diff --git a/audits/alot-requirements.audit.json b/audits/alot-requirements.audit.json index 21695b89..4851478c 100644 --- a/audits/alot-requirements.audit.json +++ b/audits/alot-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", @@ -126,12 +126,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T16:01:50Z", + "modified": "2023-11-08T04:13:41Z", "published": "2023-10-25T21:15:13Z", "schema_version": "1.6.0", "id": "GHSA-xc8x-vp79-p3wm", "aliases": [ - "CVE-2023-46137" + "CVE-2023-46137", + "PYSEC-2023-224" ], "summary": "twisted.web has disordered HTTP pipeline response", "details": "Twisted is an event-based framework for internet applications. Prior to version 23.10.0rc1, when sending multiple HTTP requests in one TCP packet, twisted.web will process the requests asynchronously without guaranteeing the response order. If one of the endpoints is controlled by an attacker, the attacker can delay the response on purpose to manipulate the response of the second request when a victim launched two requests using HTTP pipeline. Version 23.10.0rc1 contains a patch for this issue.\n\n### Details\nThere's an example faulty program:\n```python\nfrom twisted.internet import reactor, endpoints\nfrom twisted.web import server\nfrom twisted.web.proxy import ReverseProxyResource\nfrom twisted.web.resource import Resource\n\nclass Second(Resource):\n isLeaf = True\n def render_GET(self, request):\n return b'SECOND\\n'\n\nclass First(Resource):\n isLeaf = True\n def render_GET(self, request):\n def send_response():\n request.write(b'FIRST DELAYED\\n')\n request.finish()\n reactor.callLater(0.5, send_response)\n return server.NOT_DONE_YET\n\nroot = Resource()\n\nroot.putChild(b'second', Second())\nroot.putChild(b'first', First())\n\nendpoint = endpoints.TCP4ServerEndpoint(reactor, 8080)\nendpoint.listen(server.Site(root))\nreactor.run()\n```\n\nWhen two requests for `/first` and `/second` are sent in the same order, the second request will be responded to first.\n```shell\necho -en \"GET /first HTTP/1.1\\r\\nHost: a\\r\\n\\r\\nGET /second HTTP/1.1\\r\\nHost: a\\r\\n\\r\\n\" | nc localhost 8080\n```", @@ -292,7 +293,7 @@ } }, { - "modified": "2023-11-02T16:33:16Z", + "modified": "2023-11-08T04:13:41Z", "published": "2023-10-25T21:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-224", diff --git a/audits/ansible-requirements.audit.json b/audits/ansible-requirements.audit.json index 88a2e137..0df9267a 100644 --- a/audits/ansible-requirements.audit.json +++ b/audits/ansible-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2021-07-25T23:34:38Z", + "modified": "2023-11-08T03:57:53Z", "published": "2017-08-25T18:29:00Z", "schema_version": "1.6.0", "id": "PYSEC-2017-49", "aliases": [ - "CVE-2015-3206" + "CVE-2015-3206", + "PYSEC-2017-66" ], "details": "The checkPassword function in python-kerberos does not authenticate the KDC it attempts to communicate with, which allows remote attackers to cause a denial of service (bad response), or have other unspecified impact by performing a man-in-the-middle attack.", "affected": [ diff --git a/audits/athenacli-requirements.audit.json b/audits/athenacli-requirements.audit.json index 6e9dd7e5..6edc99c8 100644 --- a/audits/athenacli-requirements.audit.json +++ b/audits/athenacli-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", @@ -126,12 +126,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-05T05:23:57Z", + "modified": "2023-11-08T04:10:25Z", "published": "2023-07-19T15:30:26Z", "schema_version": "1.6.0", "id": "GHSA-mrwq-x4v8-fh7p", "aliases": [ - "CVE-2022-40896" + "CVE-2022-40896", + "PYSEC-2023-117" ], "summary": "Pygments vulnerable to ReDoS", "details": "A ReDoS issue was discovered in `pygments/lexers/smithy.py` in Pygments until 2.15.0 via SmithyLexer.", @@ -280,12 +281,13 @@ } }, { - "modified": "2023-07-19T17:26:16Z", + "modified": "2023-11-08T04:10:25Z", "published": "2023-07-19T15:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-117", "aliases": [ - "CVE-2022-40896" + "CVE-2022-40896", + "GHSA-mrwq-x4v8-fh7p" ], "details": "A ReDoS issue was discovered in pygments/lexers/smithy.py in pygments through 2.15.0 via SmithyLexer.", "affected": [ diff --git a/audits/aws-shell-requirements.audit.json b/audits/aws-shell-requirements.audit.json index 43303ad0..bf338647 100644 --- a/audits/aws-shell-requirements.audit.json +++ b/audits/aws-shell-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", diff --git a/audits/awscli-requirements.audit.json b/audits/awscli-requirements.audit.json index 485c0c7e..e2f7453f 100644 --- a/audits/awscli-requirements.audit.json +++ b/audits/awscli-requirements.audit.json @@ -13,7 +13,8 @@ "schema_version": "1.6.0", "id": "GHSA-cf7p-gm2m-833m", "aliases": [ - "CVE-2023-38325" + "CVE-2023-38325", + "PYSEC-2023-112" ], "summary": "cryptography mishandles SSH certificates", "details": "The cryptography package before 41.0.2 for Python mishandles SSH certificates that have critical options.", @@ -112,12 +113,13 @@ } }, { - "modified": "2023-08-21T15:28:13Z", + "modified": "2023-11-08T04:13:07Z", "published": "2023-07-14T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-112", "aliases": [ - "CVE-2023-38325" + "CVE-2023-38325", + "GHSA-cf7p-gm2m-833m" ], "details": "The cryptography package before 41.0.2 for Python mishandles SSH certificates that have critical options.", "affected": [ diff --git a/audits/bbot-requirements.audit.json b/audits/bbot-requirements.audit.json index dd0ddfd0..e8131577 100644 --- a/audits/bbot-requirements.audit.json +++ b/audits/bbot-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-05T05:19:34Z", + "modified": "2023-11-08T04:13:27Z", "published": "2023-10-04T15:30:35Z", "schema_version": "1.6.0", "id": "GHSA-ww3m-ffrm-qvqv", diff --git a/audits/breezy-requirements.audit.json b/audits/breezy-requirements.audit.json index 43303ad0..bf338647 100644 --- a/audits/breezy-requirements.audit.json +++ b/audits/breezy-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", diff --git a/audits/buku-requirements.audit.json b/audits/buku-requirements.audit.json index a3e34477..7c308a56 100644 --- a/audits/buku-requirements.audit.json +++ b/audits/buku-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -227,12 +228,13 @@ } }, { - "modified": "2023-11-04T00:48:52Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-02T23:27:05Z", "schema_version": "1.6.0", "id": "GHSA-v845-jxx5-vc9f", "aliases": [ - "CVE-2023-43804" + "CVE-2023-43804", + "PYSEC-2023-192" ], "summary": "`Cookie` HTTP header isn't stripped on cross-origin redirects", "details": "urllib3 doesn't treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.\n\nUsers **must** handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the `Cookie` header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.\n\n## Affected usages\n\nWe believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:\n\n* Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)\n* Using the `Cookie` header on requests, which is mostly typical for impersonating a browser.\n* Not disabling HTTP redirects\n* Either not using HTTPS or for the origin server to redirect to a malicious origin.\n\n## Remediation\n\n* Upgrading to at least urllib3 v1.26.17 or v2.0.6\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Cookie` header.", @@ -432,7 +434,7 @@ } }, { - "modified": "2023-10-10T14:28:19Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-04T17:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-192", @@ -600,7 +602,7 @@ ] }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", @@ -796,7 +798,8 @@ "schema_version": "1.6.0", "id": "GHSA-hrfv-mqp8-q5rw", "aliases": [ - "CVE-2023-46136" + "CVE-2023-46136", + "PYSEC-2023-221" ], "summary": "Werkzeug DoS: High resource usage when parsing multipart/form-data containing a large part with CR/LF character at the beginning", "details": "Werkzeug multipart data parser needs to find a boundary that may be between consecutive chunks. That's why parsing is based on looking for newline characters. Unfortunately, code looking for partial boundary in the buffer is written inefficiently, so if we upload a file that starts with CR or LF and then is followed by megabytes of data without these characters: all of these bytes are appended chunk by chunk into internal bytearray and lookup for boundary is performed on growing buffer.\n\nThis allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.\n", diff --git a/audits/bzt-requirements.audit.json b/audits/bzt-requirements.audit.json index 034b2655..db45ff8f 100644 --- a/audits/bzt-requirements.audit.json +++ b/audits/bzt-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -227,12 +228,13 @@ } }, { - "modified": "2023-11-04T00:48:52Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-02T23:27:05Z", "schema_version": "1.6.0", "id": "GHSA-v845-jxx5-vc9f", "aliases": [ - "CVE-2023-43804" + "CVE-2023-43804", + "PYSEC-2023-192" ], "summary": "`Cookie` HTTP header isn't stripped on cross-origin redirects", "details": "urllib3 doesn't treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.\n\nUsers **must** handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the `Cookie` header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.\n\n## Affected usages\n\nWe believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:\n\n* Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)\n* Using the `Cookie` header on requests, which is mostly typical for impersonating a browser.\n* Not disabling HTTP redirects\n* Either not using HTTPS or for the origin server to redirect to a malicious origin.\n\n## Remediation\n\n* Upgrading to at least urllib3 v1.26.17 or v2.0.6\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Cookie` header.", @@ -432,7 +434,7 @@ } }, { - "modified": "2023-10-10T14:28:19Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-04T17:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-192", @@ -600,7 +602,7 @@ ] }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", diff --git a/audits/certbot-requirements.audit.json b/audits/certbot-requirements.audit.json index 43303ad0..bf338647 100644 --- a/audits/certbot-requirements.audit.json +++ b/audits/certbot-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", diff --git a/audits/charm-tools-requirements.audit.json b/audits/charm-tools-requirements.audit.json index d806c6c3..114aa287 100644 --- a/audits/charm-tools-requirements.audit.json +++ b/audits/charm-tools-requirements.audit.json @@ -8,12 +8,15 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:34:35Z", + "modified": "2023-11-08T04:13:48Z", "published": "2023-10-25T18:32:26Z", "schema_version": "1.6.0", "id": "GHSA-mq26-g339-26xf", "aliases": [ - "CVE-2023-5752" + "BIT-2023-5752", + "BIT-pip-2023-5752", + "CVE-2023-5752", + "PYSEC-2023-228" ], "summary": "Command Injection in pip when used with Mercurial", "details": "When installing a package from a Mercurial VCS URL, e.g. `pip install hg+...`, with pip prior to v23.3, the specified Mercurial revision could be used to inject arbitrary configuration options to the `hg clone` call (e.g. `--config`). Controlling the Mercurial configuration can modify how and which repository is installed. This vulnerability does not affect users who aren't installing from Mercurial.", @@ -221,12 +224,15 @@ } }, { - "modified": "2023-11-03T16:28:41Z", + "modified": "2023-11-08T04:13:48Z", "published": "2023-10-25T18:17:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-228", "aliases": [ - "CVE-2023-5752" + "BIT-2023-5752", + "BIT-pip-2023-5752", + "CVE-2023-5752", + "GHSA-mq26-g339-26xf" ], "details": "When installing a package from a Mercurial VCS URL (ie \"pip install \nhg+...\") with pip prior to v23.3, the specified Mercurial revision could\n be used to inject arbitrary configuration options to the \"hg clone\" \ncall (ie \"--config\"). Controlling the Mercurial configuration can modify\n how and which repository is installed. This vulnerability does not \naffect users who aren't installing from Mercurial.\n", "affected": [ @@ -426,12 +432,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -645,7 +652,7 @@ } }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", diff --git a/audits/cycode-requirements.audit.json b/audits/cycode-requirements.audit.json index 720a7293..b6c089bd 100644 --- a/audits/cycode-requirements.audit.json +++ b/audits/cycode-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -227,7 +228,7 @@ } }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", diff --git a/audits/dstack-requirements.audit.json b/audits/dstack-requirements.audit.json index 0bb855fd..7759ed77 100644 --- a/audits/dstack-requirements.audit.json +++ b/audits/dstack-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T05:19:57Z", + "modified": "2023-11-08T04:12:36Z", "published": "2023-05-15T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-4xqq-73wg-5mjp", diff --git a/audits/dvc-requirements.audit.json b/audits/dvc-requirements.audit.json index 43303ad0..bf338647 100644 --- a/audits/dvc-requirements.audit.json +++ b/audits/dvc-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", diff --git a/audits/dxpy-requirements.audit.json b/audits/dxpy-requirements.audit.json index d61d69fa..a79f8061 100644 --- a/audits/dxpy-requirements.audit.json +++ b/audits/dxpy-requirements.audit.json @@ -13,7 +13,8 @@ "schema_version": "1.6.0", "id": "GHSA-j8r2-6x86-q33q", "aliases": [ - "CVE-2023-32681" + "CVE-2023-32681", + "PYSEC-2023-74" ], "summary": "Unintended leak of Proxy-Authorization header in requests", "details": "### Impact\n\nSince Requests v2.3.0, Requests has been vulnerable to potentially leaking `Proxy-Authorization` headers to destination servers, specifically during redirects to an HTTPS origin. This is a product of how `rebuild_proxies` is used to recompute and [reattach the `Proxy-Authorization` header](https://github.com/psf/requests/blob/f2629e9e3c7ce3c3c8c025bcd8db551101cbc773/requests/sessions.py#L319-L328) to requests when redirected. Note this behavior has _only_ been observed to affect proxied requests when credentials are supplied in the URL user information component (e.g. `https://username:password@proxy:8080`).\n\n**Current vulnerable behavior(s):**\n\n1. HTTP \u2192 HTTPS: **leak**\n2. HTTPS \u2192 HTTP: **no leak**\n3. HTTPS \u2192 HTTPS: **leak**\n4. HTTP \u2192 HTTP: **no leak**\n\nFor HTTP connections sent through the proxy, 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 further tunneled requests. This results in Requests forwarding the header to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate those credentials.\n\nThe reason this currently works for HTTPS connections in Requests is the `Proxy-Authorization` header is also handled by urllib3 with our usage of the ProxyManager in adapters.py with [`proxy_manager_for`](https://github.com/psf/requests/blob/f2629e9e3c7ce3c3c8c025bcd8db551101cbc773/requests/adapters.py#L199-L235). This will compute the required proxy headers in `proxy_headers` and pass them to the Proxy Manager, avoiding attaching them directly to the Request object. This will be our preferred option going forward for default usage.\n\n### Patches\nStarting in Requests v2.31.0, Requests will no longer attach this header to redirects with an HTTPS destination. This should have no negative impacts on the default behavior of the library as the proxy credentials are already properly being handled by urllib3's ProxyManager.\n\nFor users with custom adapters, this _may_ be potentially breaking if you were already working around this behavior. The previous functionality of `rebuild_proxies` doesn't make sense in any case, so we would encourage any users impacted to migrate any handling of Proxy-Authorization directly into their custom adapter.\n\n### Workarounds\nFor users who are not able to update Requests immediately, there is one potential workaround.\n\nYou may disable redirects by setting `allow_redirects` to `False` on all calls through Requests top-level APIs. Note that if you're currently relying on redirect behaviors, you will need to capture the 3xx response codes and ensure a new request is made to the redirect destination.\n```\nimport requests\nr = requests.get('http://github.com/', allow_redirects=False)\n```\n\n### Credits\n\nThis vulnerability was discovered and disclosed by the following individuals.\n\nDennis Brinkrolf, Haxolot (https://haxolot.com/)\nTobias Funke, (tobiasfunke93@gmail.com)", @@ -174,7 +175,7 @@ } }, { - "modified": "2023-06-05T01:13:00Z", + "modified": "2023-11-08T04:12:35Z", "published": "2023-05-26T18:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-74", diff --git a/audits/esphome-requirements.audit.json b/audits/esphome-requirements.audit.json index f6c938e7..74a9d851 100644 --- a/audits/esphome-requirements.audit.json +++ b/audits/esphome-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-09T22:26:48Z", + "modified": "2023-11-09T22:41:37Z", "published": "2023-11-09T18:34:55Z", "schema_version": "1.6.0", "id": "GHSA-3f38-96qm-r3fw", diff --git a/audits/flintrock-requirements.audit.json b/audits/flintrock-requirements.audit.json index 2d7abf3a..74a8c989 100644 --- a/audits/flintrock-requirements.audit.json +++ b/audits/flintrock-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2022-05-17T03:06:38Z", + "modified": "2023-11-08T04:08:30Z", "published": "2022-03-17T22:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2022-166", @@ -210,12 +210,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -429,12 +430,13 @@ } }, { - "modified": "2023-11-04T00:48:52Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-02T23:27:05Z", "schema_version": "1.6.0", "id": "GHSA-v845-jxx5-vc9f", "aliases": [ - "CVE-2023-43804" + "CVE-2023-43804", + "PYSEC-2023-192" ], "summary": "`Cookie` HTTP header isn't stripped on cross-origin redirects", "details": "urllib3 doesn't treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.\n\nUsers **must** handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the `Cookie` header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.\n\n## Affected usages\n\nWe believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:\n\n* Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)\n* Using the `Cookie` header on requests, which is mostly typical for impersonating a browser.\n* Not disabling HTTP redirects\n* Either not using HTTPS or for the origin server to redirect to a malicious origin.\n\n## Remediation\n\n* Upgrading to at least urllib3 v1.26.17 or v2.0.6\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Cookie` header.", @@ -634,7 +636,7 @@ } }, { - "modified": "2023-10-10T14:28:19Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-04T17:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-192", @@ -802,7 +804,7 @@ ] }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", diff --git a/audits/gyb-requirements.audit.json b/audits/gyb-requirements.audit.json index 034b2655..db45ff8f 100644 --- a/audits/gyb-requirements.audit.json +++ b/audits/gyb-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -227,12 +228,13 @@ } }, { - "modified": "2023-11-04T00:48:52Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-02T23:27:05Z", "schema_version": "1.6.0", "id": "GHSA-v845-jxx5-vc9f", "aliases": [ - "CVE-2023-43804" + "CVE-2023-43804", + "PYSEC-2023-192" ], "summary": "`Cookie` HTTP header isn't stripped on cross-origin redirects", "details": "urllib3 doesn't treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.\n\nUsers **must** handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the `Cookie` header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.\n\n## Affected usages\n\nWe believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:\n\n* Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)\n* Using the `Cookie` header on requests, which is mostly typical for impersonating a browser.\n* Not disabling HTTP redirects\n* Either not using HTTPS or for the origin server to redirect to a malicious origin.\n\n## Remediation\n\n* Upgrading to at least urllib3 v1.26.17 or v2.0.6\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Cookie` header.", @@ -432,7 +434,7 @@ } }, { - "modified": "2023-10-10T14:28:19Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-04T17:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-192", @@ -600,7 +602,7 @@ ] }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", diff --git a/audits/howdoi-requirements.audit.json b/audits/howdoi-requirements.audit.json index 30eb4098..d47e79d4 100644 --- a/audits/howdoi-requirements.audit.json +++ b/audits/howdoi-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-08-17T03:22:31Z", + "modified": "2023-11-08T04:09:20Z", "published": "2022-06-08T18:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2022-43056", diff --git a/audits/iredis-requirements.audit.json b/audits/iredis-requirements.audit.json index 43303ad0..bf338647 100644 --- a/audits/iredis-requirements.audit.json +++ b/audits/iredis-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", diff --git a/audits/jenkins-job-builder-requirements.audit.json b/audits/jenkins-job-builder-requirements.audit.json index aaee1072..73194a85 100644 --- a/audits/jenkins-job-builder-requirements.audit.json +++ b/audits/jenkins-job-builder-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -227,7 +228,7 @@ } }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", diff --git a/audits/khal-requirements.audit.json b/audits/khal-requirements.audit.json index 43303ad0..bf338647 100644 --- a/audits/khal-requirements.audit.json +++ b/audits/khal-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", diff --git a/audits/khard-requirements.audit.json b/audits/khard-requirements.audit.json index 43303ad0..bf338647 100644 --- a/audits/khard-requirements.audit.json +++ b/audits/khard-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", diff --git a/audits/litecli-requirements.audit.json b/audits/litecli-requirements.audit.json index 43303ad0..bf338647 100644 --- a/audits/litecli-requirements.audit.json +++ b/audits/litecli-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", diff --git a/audits/literate-git-requirements.audit.json b/audits/literate-git-requirements.audit.json index 09169e73..360e7f7e 100644 --- a/audits/literate-git-requirements.audit.json +++ b/audits/literate-git-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-10-22T05:32:34Z", + "modified": "2023-11-08T04:04:36Z", "published": "2021-04-20T16:35:47Z", "schema_version": "1.6.0", "id": "GHSA-9w8r-397f-prfh", "aliases": [ - "CVE-2021-20270" + "CVE-2021-20270", + "PYSEC-2021-140" ], "summary": "Infinite Loop in Pygments", "details": "An infinite loop in SMLLexer in Pygments versions 1.5 to 2.7.3 may lead to denial of service when performing syntax highlighting of a Standard ML (SML) source file, as demonstrated by input that only contains the \"exception\" keyword.", @@ -120,12 +121,13 @@ } }, { - "modified": "2023-11-05T05:23:57Z", + "modified": "2023-11-08T04:10:25Z", "published": "2023-07-19T15:30:26Z", "schema_version": "1.6.0", "id": "GHSA-mrwq-x4v8-fh7p", "aliases": [ - "CVE-2022-40896" + "CVE-2022-40896", + "PYSEC-2023-117" ], "summary": "Pygments vulnerable to ReDoS", "details": "A ReDoS issue was discovered in `pygments/lexers/smithy.py` in Pygments until 2.15.0 via SmithyLexer.", @@ -274,12 +276,13 @@ } }, { - "modified": "2023-10-22T05:32:03Z", + "modified": "2023-11-08T04:05:24Z", "published": "2021-03-29T16:33:03Z", "schema_version": "1.6.0", "id": "GHSA-pq64-v7f5-gqh8", "aliases": [ - "CVE-2021-27291" + "CVE-2021-27291", + "PYSEC-2021-141" ], "summary": "Pygments vulnerable to Regular Expression Denial of Service (ReDoS)", "details": "In pygments 1.1+, fixed in 2.7.4, the lexers used to parse programming languages rely heavily on regular expressions. Some of the regular expressions have exponential or cubic worst-case complexity and are vulnerable to ReDoS. By crafting malicious input, an attacker can cause a denial of service.", @@ -406,7 +409,7 @@ } }, { - "modified": "2021-08-27T03:22:17Z", + "modified": "2023-11-08T04:04:36Z", "published": "2021-03-23T17:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2021-140", @@ -491,7 +494,7 @@ ] }, { - "modified": "2021-08-27T03:22:17Z", + "modified": "2023-11-08T04:05:24Z", "published": "2021-03-17T13:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2021-141", @@ -616,12 +619,13 @@ ] }, { - "modified": "2023-07-19T17:26:16Z", + "modified": "2023-11-08T04:10:25Z", "published": "2023-07-19T15:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-117", "aliases": [ - "CVE-2022-40896" + "CVE-2022-40896", + "GHSA-mrwq-x4v8-fh7p" ], "details": "A ReDoS issue was discovered in pygments/lexers/smithy.py in pygments through 2.15.0 via SmithyLexer.", "affected": [ diff --git a/audits/magic-wormhole-requirements.audit.json b/audits/magic-wormhole-requirements.audit.json index ee809a50..b56bdaad 100644 --- a/audits/magic-wormhole-requirements.audit.json +++ b/audits/magic-wormhole-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T16:01:50Z", + "modified": "2023-11-08T04:13:41Z", "published": "2023-10-25T21:15:13Z", "schema_version": "1.6.0", "id": "GHSA-xc8x-vp79-p3wm", "aliases": [ - "CVE-2023-46137" + "CVE-2023-46137", + "PYSEC-2023-224" ], "summary": "twisted.web has disordered HTTP pipeline response", "details": "Twisted is an event-based framework for internet applications. Prior to version 23.10.0rc1, when sending multiple HTTP requests in one TCP packet, twisted.web will process the requests asynchronously without guaranteeing the response order. If one of the endpoints is controlled by an attacker, the attacker can delay the response on purpose to manipulate the response of the second request when a victim launched two requests using HTTP pipeline. Version 23.10.0rc1 contains a patch for this issue.\n\n### Details\nThere's an example faulty program:\n```python\nfrom twisted.internet import reactor, endpoints\nfrom twisted.web import server\nfrom twisted.web.proxy import ReverseProxyResource\nfrom twisted.web.resource import Resource\n\nclass Second(Resource):\n isLeaf = True\n def render_GET(self, request):\n return b'SECOND\\n'\n\nclass First(Resource):\n isLeaf = True\n def render_GET(self, request):\n def send_response():\n request.write(b'FIRST DELAYED\\n')\n request.finish()\n reactor.callLater(0.5, send_response)\n return server.NOT_DONE_YET\n\nroot = Resource()\n\nroot.putChild(b'second', Second())\nroot.putChild(b'first', First())\n\nendpoint = endpoints.TCP4ServerEndpoint(reactor, 8080)\nendpoint.listen(server.Site(root))\nreactor.run()\n```\n\nWhen two requests for `/first` and `/second` are sent in the same order, the second request will be responded to first.\n```shell\necho -en \"GET /first HTTP/1.1\\r\\nHost: a\\r\\n\\r\\nGET /second HTTP/1.1\\r\\nHost: a\\r\\n\\r\\n\" | nc localhost 8080\n```", @@ -174,7 +175,7 @@ } }, { - "modified": "2023-11-02T16:33:16Z", + "modified": "2023-11-08T04:13:41Z", "published": "2023-10-25T21:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-224", diff --git a/audits/mvt-requirements.audit.json b/audits/mvt-requirements.audit.json index aaee1072..73194a85 100644 --- a/audits/mvt-requirements.audit.json +++ b/audits/mvt-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -227,7 +228,7 @@ } }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", diff --git a/audits/mycli-requirements.audit.json b/audits/mycli-requirements.audit.json index 43303ad0..bf338647 100644 --- a/audits/mycli-requirements.audit.json +++ b/audits/mycli-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", diff --git a/audits/onlykey-agent-requirements.audit.json b/audits/onlykey-agent-requirements.audit.json index cbcc5a53..f4bb7ad7 100644 --- a/audits/onlykey-agent-requirements.audit.json +++ b/audits/onlykey-agent-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -227,12 +228,13 @@ } }, { - "modified": "2023-11-04T00:48:52Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-02T23:27:05Z", "schema_version": "1.6.0", "id": "GHSA-v845-jxx5-vc9f", "aliases": [ - "CVE-2023-43804" + "CVE-2023-43804", + "PYSEC-2023-192" ], "summary": "`Cookie` HTTP header isn't stripped on cross-origin redirects", "details": "urllib3 doesn't treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.\n\nUsers **must** handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the `Cookie` header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.\n\n## Affected usages\n\nWe believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:\n\n* Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)\n* Using the `Cookie` header on requests, which is mostly typical for impersonating a browser.\n* Not disabling HTTP redirects\n* Either not using HTTPS or for the origin server to redirect to a malicious origin.\n\n## Remediation\n\n* Upgrading to at least urllib3 v1.26.17 or v2.0.6\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Cookie` header.", @@ -432,7 +434,7 @@ } }, { - "modified": "2023-10-10T14:28:19Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-04T17:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-192", @@ -600,7 +602,7 @@ ] }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", diff --git a/audits/pgcli-requirements.audit.json b/audits/pgcli-requirements.audit.json index 43303ad0..bf338647 100644 --- a/audits/pgcli-requirements.audit.json +++ b/audits/pgcli-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", diff --git a/audits/pypy-requirements.audit.json b/audits/pypy-requirements.audit.json index 05d655f7..1c306723 100644 --- a/audits/pypy-requirements.audit.json +++ b/audits/pypy-requirements.audit.json @@ -8,12 +8,15 @@ }, "vulnerabilities": [ { - "modified": "2023-04-11T01:15:33Z", + "modified": "2023-11-08T04:06:10Z", "published": "2021-11-15T17:45:01Z", "schema_version": "1.6.0", "id": "GHSA-5xp3-jfq3-5q8x", "aliases": [ - "CVE-2021-3572" + "BIT-2021-3572", + "BIT-pip-2021-3572", + "CVE-2021-3572", + "PYSEC-2021-437" ], "summary": "Improper Input Validation in pip", "details": "A flaw was found in python-pip in the way it handled Unicode separators in git references. A remote attacker could possibly use this issue to install a different revision on a repository. The highest threat from this vulnerability is to data integrity. This is fixed in python-pip version 21.1.", @@ -201,12 +204,15 @@ } }, { - "modified": "2023-11-06T16:34:35Z", + "modified": "2023-11-08T04:13:48Z", "published": "2023-10-25T18:32:26Z", "schema_version": "1.6.0", "id": "GHSA-mq26-g339-26xf", "aliases": [ - "CVE-2023-5752" + "BIT-2023-5752", + "BIT-pip-2023-5752", + "CVE-2023-5752", + "PYSEC-2023-228" ], "summary": "Command Injection in pip when used with Mercurial", "details": "When installing a package from a Mercurial VCS URL, e.g. `pip install hg+...`, with pip prior to v23.3, the specified Mercurial revision could be used to inject arbitrary configuration options to the `hg clone` call (e.g. `--config`). Controlling the Mercurial configuration can modify how and which repository is installed. This vulnerability does not affect users who aren't installing from Mercurial.", @@ -414,11 +420,13 @@ } }, { - "modified": "2021-11-29T23:42:09Z", + "modified": "2023-11-08T04:06:10Z", "published": "2021-11-10T18:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2021-437", "aliases": [ + "BIT-2021-3572", + "BIT-pip-2021-3572", "CVE-2021-3572", "GHSA-5xp3-jfq3-5q8x" ], @@ -564,12 +572,15 @@ ] }, { - "modified": "2023-11-03T16:28:41Z", + "modified": "2023-11-08T04:13:48Z", "published": "2023-10-25T18:17:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-228", "aliases": [ - "CVE-2023-5752" + "BIT-2023-5752", + "BIT-pip-2023-5752", + "CVE-2023-5752", + "GHSA-mq26-g339-26xf" ], "details": "When installing a package from a Mercurial VCS URL (ie \"pip install \nhg+...\") with pip prior to v23.3, the specified Mercurial revision could\n be used to inject arbitrary configuration options to the \"hg clone\" \ncall (ie \"--config\"). Controlling the Mercurial configuration can modify\n how and which repository is installed. This vulnerability does not \naffect users who aren't installing from Mercurial.\n", "affected": [ @@ -775,12 +786,15 @@ }, "vulnerabilities": [ { - "modified": "2023-05-01T14:02:28Z", + "modified": "2023-11-08T04:10:26Z", "published": "2022-12-23T00:30:23Z", "schema_version": "1.6.0", "id": "GHSA-r9hx-vwmv-q579", "aliases": [ - "CVE-2022-40897" + "BIT-2022-40897", + "BIT-setuptools-2022-40897", + "CVE-2022-40897", + "PYSEC-2022-43012" ], "summary": "pypa/setuptools vulnerable to Regular Expression Denial of Service (ReDoS)", "details": "Python Packaging Authority (PyPA)'s setuptools is a library designed to facilitate packaging Python projects. Setuptools version 65.5.0 and earlier could allow remote attackers to cause a denial of service by fetching malicious HTML from a PyPI package or custom PackageIndex page due to a vulnerable Regular Expression in `package_index`. This has been patched in version 65.5.1.", @@ -1392,12 +1406,15 @@ } }, { - "modified": "2023-05-04T04:29:29Z", + "modified": "2023-11-08T04:10:26Z", "published": "2022-12-23T00:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2022-43012", "aliases": [ - "CVE-2022-40897" + "BIT-2022-40897", + "BIT-setuptools-2022-40897", + "CVE-2022-40897", + "GHSA-r9hx-vwmv-q579" ], "details": "Python Packaging Authority (PyPA) setuptools before 65.5.1 allows remote attackers to cause a denial of service via HTML in a crafted package or custom PackageIndex page. There is a Regular Expression Denial of Service (ReDoS) in package_index.py.", "affected": [ diff --git a/audits/pypy3.10-requirements.audit.json b/audits/pypy3.10-requirements.audit.json index 2858123e..94adc6f9 100644 --- a/audits/pypy3.10-requirements.audit.json +++ b/audits/pypy3.10-requirements.audit.json @@ -8,12 +8,15 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:34:35Z", + "modified": "2023-11-08T04:13:48Z", "published": "2023-10-25T18:32:26Z", "schema_version": "1.6.0", "id": "GHSA-mq26-g339-26xf", "aliases": [ - "CVE-2023-5752" + "BIT-2023-5752", + "BIT-pip-2023-5752", + "CVE-2023-5752", + "PYSEC-2023-228" ], "summary": "Command Injection in pip when used with Mercurial", "details": "When installing a package from a Mercurial VCS URL, e.g. `pip install hg+...`, with pip prior to v23.3, the specified Mercurial revision could be used to inject arbitrary configuration options to the `hg clone` call (e.g. `--config`). Controlling the Mercurial configuration can modify how and which repository is installed. This vulnerability does not affect users who aren't installing from Mercurial.", @@ -221,12 +224,15 @@ } }, { - "modified": "2023-11-03T16:28:41Z", + "modified": "2023-11-08T04:13:48Z", "published": "2023-10-25T18:17:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-228", "aliases": [ - "CVE-2023-5752" + "BIT-2023-5752", + "BIT-pip-2023-5752", + "CVE-2023-5752", + "GHSA-mq26-g339-26xf" ], "details": "When installing a package from a Mercurial VCS URL (ie \"pip install \nhg+...\") with pip prior to v23.3, the specified Mercurial revision could\n be used to inject arbitrary configuration options to the \"hg clone\" \ncall (ie \"--config\"). Controlling the Mercurial configuration can modify\n how and which repository is installed. This vulnerability does not \naffect users who aren't installing from Mercurial.\n", "affected": [ @@ -426,12 +432,15 @@ }, "vulnerabilities": [ { - "modified": "2023-05-01T14:02:28Z", + "modified": "2023-11-08T04:10:26Z", "published": "2022-12-23T00:30:23Z", "schema_version": "1.6.0", "id": "GHSA-r9hx-vwmv-q579", "aliases": [ - "CVE-2022-40897" + "BIT-2022-40897", + "BIT-setuptools-2022-40897", + "CVE-2022-40897", + "PYSEC-2022-43012" ], "summary": "pypa/setuptools vulnerable to Regular Expression Denial of Service (ReDoS)", "details": "Python Packaging Authority (PyPA)'s setuptools is a library designed to facilitate packaging Python projects. Setuptools version 65.5.0 and earlier could allow remote attackers to cause a denial of service by fetching malicious HTML from a PyPI package or custom PackageIndex page due to a vulnerable Regular Expression in `package_index`. This has been patched in version 65.5.1.", @@ -1043,12 +1052,15 @@ } }, { - "modified": "2023-05-04T04:29:29Z", + "modified": "2023-11-08T04:10:26Z", "published": "2022-12-23T00:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2022-43012", "aliases": [ - "CVE-2022-40897" + "BIT-2022-40897", + "BIT-setuptools-2022-40897", + "CVE-2022-40897", + "GHSA-r9hx-vwmv-q579" ], "details": "Python Packaging Authority (PyPA) setuptools before 65.5.1 allows remote attackers to cause a denial of service via HTML in a crafted package or custom PackageIndex page. There is a Regular Expression Denial of Service (ReDoS) in package_index.py.", "affected": [ diff --git a/audits/pypy3.9-requirements.audit.json b/audits/pypy3.9-requirements.audit.json index 2858123e..94adc6f9 100644 --- a/audits/pypy3.9-requirements.audit.json +++ b/audits/pypy3.9-requirements.audit.json @@ -8,12 +8,15 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:34:35Z", + "modified": "2023-11-08T04:13:48Z", "published": "2023-10-25T18:32:26Z", "schema_version": "1.6.0", "id": "GHSA-mq26-g339-26xf", "aliases": [ - "CVE-2023-5752" + "BIT-2023-5752", + "BIT-pip-2023-5752", + "CVE-2023-5752", + "PYSEC-2023-228" ], "summary": "Command Injection in pip when used with Mercurial", "details": "When installing a package from a Mercurial VCS URL, e.g. `pip install hg+...`, with pip prior to v23.3, the specified Mercurial revision could be used to inject arbitrary configuration options to the `hg clone` call (e.g. `--config`). Controlling the Mercurial configuration can modify how and which repository is installed. This vulnerability does not affect users who aren't installing from Mercurial.", @@ -221,12 +224,15 @@ } }, { - "modified": "2023-11-03T16:28:41Z", + "modified": "2023-11-08T04:13:48Z", "published": "2023-10-25T18:17:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-228", "aliases": [ - "CVE-2023-5752" + "BIT-2023-5752", + "BIT-pip-2023-5752", + "CVE-2023-5752", + "GHSA-mq26-g339-26xf" ], "details": "When installing a package from a Mercurial VCS URL (ie \"pip install \nhg+...\") with pip prior to v23.3, the specified Mercurial revision could\n be used to inject arbitrary configuration options to the \"hg clone\" \ncall (ie \"--config\"). Controlling the Mercurial configuration can modify\n how and which repository is installed. This vulnerability does not \naffect users who aren't installing from Mercurial.\n", "affected": [ @@ -426,12 +432,15 @@ }, "vulnerabilities": [ { - "modified": "2023-05-01T14:02:28Z", + "modified": "2023-11-08T04:10:26Z", "published": "2022-12-23T00:30:23Z", "schema_version": "1.6.0", "id": "GHSA-r9hx-vwmv-q579", "aliases": [ - "CVE-2022-40897" + "BIT-2022-40897", + "BIT-setuptools-2022-40897", + "CVE-2022-40897", + "PYSEC-2022-43012" ], "summary": "pypa/setuptools vulnerable to Regular Expression Denial of Service (ReDoS)", "details": "Python Packaging Authority (PyPA)'s setuptools is a library designed to facilitate packaging Python projects. Setuptools version 65.5.0 and earlier could allow remote attackers to cause a denial of service by fetching malicious HTML from a PyPI package or custom PackageIndex page due to a vulnerable Regular Expression in `package_index`. This has been patched in version 65.5.1.", @@ -1043,12 +1052,15 @@ } }, { - "modified": "2023-05-04T04:29:29Z", + "modified": "2023-11-08T04:10:26Z", "published": "2022-12-23T00:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2022-43012", "aliases": [ - "CVE-2022-40897" + "BIT-2022-40897", + "BIT-setuptools-2022-40897", + "CVE-2022-40897", + "GHSA-r9hx-vwmv-q579" ], "details": "Python Packaging Authority (PyPA) setuptools before 65.5.1 allows remote attackers to cause a denial of service via HTML in a crafted package or custom PackageIndex page. There is a Regular Expression Denial of Service (ReDoS) in package_index.py.", "affected": [ diff --git a/audits/python@3.12-requirements.audit.json b/audits/python@3.12-requirements.audit.json index 59625655..6c22753f 100644 --- a/audits/python@3.12-requirements.audit.json +++ b/audits/python@3.12-requirements.audit.json @@ -8,12 +8,15 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:34:35Z", + "modified": "2023-11-08T04:13:48Z", "published": "2023-10-25T18:32:26Z", "schema_version": "1.6.0", "id": "GHSA-mq26-g339-26xf", "aliases": [ - "CVE-2023-5752" + "BIT-2023-5752", + "BIT-pip-2023-5752", + "CVE-2023-5752", + "PYSEC-2023-228" ], "summary": "Command Injection in pip when used with Mercurial", "details": "When installing a package from a Mercurial VCS URL, e.g. `pip install hg+...`, with pip prior to v23.3, the specified Mercurial revision could be used to inject arbitrary configuration options to the `hg clone` call (e.g. `--config`). Controlling the Mercurial configuration can modify how and which repository is installed. This vulnerability does not affect users who aren't installing from Mercurial.", @@ -221,12 +224,15 @@ } }, { - "modified": "2023-11-03T16:28:41Z", + "modified": "2023-11-08T04:13:48Z", "published": "2023-10-25T18:17:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-228", "aliases": [ - "CVE-2023-5752" + "BIT-2023-5752", + "BIT-pip-2023-5752", + "CVE-2023-5752", + "GHSA-mq26-g339-26xf" ], "details": "When installing a package from a Mercurial VCS URL (ie \"pip install \nhg+...\") with pip prior to v23.3, the specified Mercurial revision could\n be used to inject arbitrary configuration options to the \"hg clone\" \ncall (ie \"--config\"). Controlling the Mercurial configuration can modify\n how and which repository is installed. This vulnerability does not \naffect users who aren't installing from Mercurial.\n", "affected": [ diff --git a/audits/recon-ng-requirements.audit.json b/audits/recon-ng-requirements.audit.json index d4ab4704..db14927f 100644 --- a/audits/recon-ng-requirements.audit.json +++ b/audits/recon-ng-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T05:23:02Z", + "modified": "2023-11-08T04:12:28Z", "published": "2023-05-01T19:22:20Z", "schema_version": "1.6.0", "id": "GHSA-m2qf-hxjv-5gpq", "aliases": [ - "CVE-2023-30861" + "CVE-2023-30861", + "PYSEC-2023-62" ], "summary": "Flask vulnerable to possible disclosure of permanent session cookie due to missing Vary: Cookie header", "details": "When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by a proxy to other clients. If the proxy also caches `Set-Cookie` headers, it may send one client's `session` cookie to other clients. The severity depends on the application's use of the session, and the proxy's behavior regarding cookies. The risk depends on _all_ these conditions being met.\n\n1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.\n2. The application sets [`session.permanent = True`](https://flask.palletsprojects.com/en/2.3.x/api/#flask.session.permanent).\n2. The application does not access or modify the session at any point during a request.\n4. [`SESSION_REFRESH_EACH_REQUEST`](https://flask.palletsprojects.com/en/2.3.x/config/#SESSION_REFRESH_EACH_REQUEST) is enabled (the default).\n5. The application does not set a `Cache-Control` header to indicate that a page is private or should not be cached.\n\nThis happens because vulnerable versions of Flask only set the `Vary: Cookie` header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.", @@ -195,7 +196,7 @@ } }, { - "modified": "2023-06-05T01:12:52Z", + "modified": "2023-11-08T04:12:28Z", "published": "2023-05-02T18:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-62", @@ -347,12 +348,13 @@ }, "vulnerabilities": [ { - "modified": "2023-06-06T18:18:13Z", + "modified": "2023-11-08T04:12:15Z", "published": "2023-03-26T21:30:23Z", "schema_version": "1.6.0", "id": "GHSA-24wv-mv5m-xv4h", "aliases": [ - "CVE-2023-28858" + "CVE-2023-28858", + "PYSEC-2023-45" ], "summary": "redis-py Race Condition vulnerability", "details": "redis-py before 4.5.3, as used in ChatGPT and other products, leaves a connection open after canceling an async Redis command at an inopportune time (in the case of a pipeline operation), and can send response data to the client of an unrelated request in an off-by-one manner. The fixed versions for this CVE Record are 4.3.6, 4.4.3, and 4.5.3, but [are believed to be incomplete](https://github.com/redis/redis-py/issues/2665). CVE-2023-28859 has been assigned the issues caused by the incomplete fixes.", @@ -515,12 +517,13 @@ } }, { - "modified": "2023-07-19T22:49:04Z", + "modified": "2023-11-08T04:12:15Z", "published": "2023-03-26T21:30:23Z", "schema_version": "1.6.0", "id": "GHSA-8fww-64cx-x8p5", "aliases": [ - "CVE-2023-28859" + "CVE-2023-28859", + "PYSEC-2023-46" ], "summary": "redis-py Race Condition due to incomplete fix", "details": "redis-py through 4.5.3 and 4.4.3 leaves a connection open after canceling an async Redis command at an inopportune time (in the case of a non-pipeline operation), and can send response data to the client of an unrelated request. NOTE: this issue exists because of an incomplete fix for CVE-2023-28858.", @@ -675,12 +678,13 @@ } }, { - "modified": "2023-06-05T01:13:00Z", + "modified": "2023-11-08T04:12:15Z", "published": "2023-03-26T19:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-45", "aliases": [ - "CVE-2023-28858" + "CVE-2023-28858", + "GHSA-24wv-mv5m-xv4h" ], "details": "redis-py before 4.5.3, as used in ChatGPT and other products, leaves a connection open after canceling an async Redis command at an inopportune time (in the case of a pipeline operation), and can send response data to the client of an unrelated request in an off-by-one manner. The fixed versions for this CVE Record are 4.3.6, 4.4.3, and 4.5.3; however, CVE-2023-28859 is a separate vulnerability.", "affected": [ @@ -765,12 +769,13 @@ ] }, { - "modified": "2023-06-05T01:13:00Z", + "modified": "2023-11-08T04:12:15Z", "published": "2023-03-26T19:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-46", "aliases": [ - "CVE-2023-28859" + "CVE-2023-28859", + "GHSA-8fww-64cx-x8p5" ], "details": "redis-py through 4.5.3 leaves a connection open after canceling an async Redis command at an inopportune time (in the case of a non-pipeline operation), and can send response data to the client of an unrelated request. NOTE: this issue exists because of an incomplete fix for CVE-2023-28858.", "affected": [ @@ -869,7 +874,8 @@ "schema_version": "1.6.0", "id": "GHSA-j8r2-6x86-q33q", "aliases": [ - "CVE-2023-32681" + "CVE-2023-32681", + "PYSEC-2023-74" ], "summary": "Unintended leak of Proxy-Authorization header in requests", "details": "### Impact\n\nSince Requests v2.3.0, Requests has been vulnerable to potentially leaking `Proxy-Authorization` headers to destination servers, specifically during redirects to an HTTPS origin. This is a product of how `rebuild_proxies` is used to recompute and [reattach the `Proxy-Authorization` header](https://github.com/psf/requests/blob/f2629e9e3c7ce3c3c8c025bcd8db551101cbc773/requests/sessions.py#L319-L328) to requests when redirected. Note this behavior has _only_ been observed to affect proxied requests when credentials are supplied in the URL user information component (e.g. `https://username:password@proxy:8080`).\n\n**Current vulnerable behavior(s):**\n\n1. HTTP \u2192 HTTPS: **leak**\n2. HTTPS \u2192 HTTP: **no leak**\n3. HTTPS \u2192 HTTPS: **leak**\n4. HTTP \u2192 HTTP: **no leak**\n\nFor HTTP connections sent through the proxy, 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 further tunneled requests. This results in Requests forwarding the header to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate those credentials.\n\nThe reason this currently works for HTTPS connections in Requests is the `Proxy-Authorization` header is also handled by urllib3 with our usage of the ProxyManager in adapters.py with [`proxy_manager_for`](https://github.com/psf/requests/blob/f2629e9e3c7ce3c3c8c025bcd8db551101cbc773/requests/adapters.py#L199-L235). This will compute the required proxy headers in `proxy_headers` and pass them to the Proxy Manager, avoiding attaching them directly to the Request object. This will be our preferred option going forward for default usage.\n\n### Patches\nStarting in Requests v2.31.0, Requests will no longer attach this header to redirects with an HTTPS destination. This should have no negative impacts on the default behavior of the library as the proxy credentials are already properly being handled by urllib3's ProxyManager.\n\nFor users with custom adapters, this _may_ be potentially breaking if you were already working around this behavior. The previous functionality of `rebuild_proxies` doesn't make sense in any case, so we would encourage any users impacted to migrate any handling of Proxy-Authorization directly into their custom adapter.\n\n### Workarounds\nFor users who are not able to update Requests immediately, there is one potential workaround.\n\nYou may disable redirects by setting `allow_redirects` to `False` on all calls through Requests top-level APIs. Note that if you're currently relying on redirect behaviors, you will need to capture the 3xx response codes and ensure a new request is made to the redirect destination.\n```\nimport requests\nr = requests.get('http://github.com/', allow_redirects=False)\n```\n\n### Credits\n\nThis vulnerability was discovered and disclosed by the following individuals.\n\nDennis Brinkrolf, Haxolot (https://haxolot.com/)\nTobias Funke, (tobiasfunke93@gmail.com)", @@ -1030,7 +1036,7 @@ } }, { - "modified": "2023-06-05T01:13:00Z", + "modified": "2023-11-08T04:12:35Z", "published": "2023-05-26T18:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-74", @@ -1182,12 +1188,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -1401,12 +1408,13 @@ } }, { - "modified": "2023-11-04T00:48:52Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-02T23:27:05Z", "schema_version": "1.6.0", "id": "GHSA-v845-jxx5-vc9f", "aliases": [ - "CVE-2023-43804" + "CVE-2023-43804", + "PYSEC-2023-192" ], "summary": "`Cookie` HTTP header isn't stripped on cross-origin redirects", "details": "urllib3 doesn't treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.\n\nUsers **must** handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the `Cookie` header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.\n\n## Affected usages\n\nWe believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:\n\n* Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)\n* Using the `Cookie` header on requests, which is mostly typical for impersonating a browser.\n* Not disabling HTTP redirects\n* Either not using HTTPS or for the origin server to redirect to a malicious origin.\n\n## Remediation\n\n* Upgrading to at least urllib3 v1.26.17 or v2.0.6\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Cookie` header.", @@ -1606,7 +1614,7 @@ } }, { - "modified": "2023-10-10T14:28:19Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-04T17:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-192", @@ -1774,7 +1782,7 @@ ] }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", @@ -1970,7 +1978,8 @@ "schema_version": "1.6.0", "id": "GHSA-hrfv-mqp8-q5rw", "aliases": [ - "CVE-2023-46136" + "CVE-2023-46136", + "PYSEC-2023-221" ], "summary": "Werkzeug DoS: High resource usage when parsing multipart/form-data containing a large part with CR/LF character at the beginning", "details": "Werkzeug multipart data parser needs to find a boundary that may be between consecutive chunks. That's why parsing is based on looking for newline characters. Unfortunately, code looking for partial boundary in the buffer is written inefficiently, so if we upload a file that starts with CR or LF and then is followed by megabytes of data without these characters: all of these bytes are appended chunk by chunk into internal bytearray and lookup for boundary is performed on growing buffer.\n\nThis allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.\n", @@ -2174,12 +2183,13 @@ } }, { - "modified": "2023-08-18T16:01:11Z", + "modified": "2023-11-08T04:11:43Z", "published": "2023-02-15T15:37:03Z", "schema_version": "1.6.0", "id": "GHSA-px8h-6qxv-m22q", "aliases": [ - "CVE-2023-23934" + "CVE-2023-23934", + "PYSEC-2023-57" ], "summary": "Incorrect parsing of nameless cookies leads to __Host- cookies bypass", "details": "Browsers may allow \"nameless\" cookies that look like `=value` instead of `key=value`. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like `=__Host-test=bad` for another subdomain.\n\nWerkzeug <= 2.2.2 will parse the cookie `=__Host-test=bad` as `__Host-test=bad`. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.", @@ -2342,12 +2352,13 @@ } }, { - "modified": "2023-08-18T16:01:28Z", + "modified": "2023-11-08T04:11:52Z", "published": "2023-02-15T15:36:26Z", "schema_version": "1.6.0", "id": "GHSA-xg9f-g7g7-2323", "aliases": [ - "CVE-2023-25577" + "CVE-2023-25577", + "PYSEC-2023-58" ], "summary": "High resource usage when parsing multipart form data with many fields", "details": "Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses `request.data`, `request.form`, `request.files`, or `request.get_data(parse_form_data=False)`, it can cause unexpectedly high resource usage.\n\nThis allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.", @@ -2676,7 +2687,7 @@ ] }, { - "modified": "2023-05-04T03:49:48Z", + "modified": "2023-11-08T04:11:43Z", "published": "2023-02-14T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-57", @@ -2820,7 +2831,7 @@ ] }, { - "modified": "2023-05-04T03:49:48Z", + "modified": "2023-11-08T04:11:52Z", "published": "2023-02-14T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-58", diff --git a/audits/scoutsuite-requirements.audit.json b/audits/scoutsuite-requirements.audit.json deleted file mode 100644 index 034b2655..00000000 --- a/audits/scoutsuite-requirements.audit.json +++ /dev/null @@ -1,785 +0,0 @@ -[ - { - "package": { - "name": "urllib3", - "version": "1.26.16", - "ecosystem": "PyPI", - "commit": "" - }, - "vulnerabilities": [ - { - "modified": "2023-11-06T16:43:34Z", - "published": "2023-10-17T20:15:25Z", - "schema_version": "1.6.0", - "id": "GHSA-g4mx-q9vg-27p4", - "aliases": [ - "CVE-2023-45803" - ], - "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", - "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", - "affected": [ - { - "package": { - "ecosystem": "PyPI", - "name": "urllib3", - "purl": "pkg:pypi/urllib3" - }, - "ranges": [ - { - "type": "ECOSYSTEM", - "events": [ - { - "introduced": "2.0.0" - }, - { - "fixed": "2.0.7" - } - ] - } - ], - "versions": [ - "2.0.0", - "2.0.1", - "2.0.2", - "2.0.3", - "2.0.4", - "2.0.5", - "2.0.6" - ], - "database_specific": { - "source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2023/10/GHSA-g4mx-q9vg-27p4/GHSA-g4mx-q9vg-27p4.json" - } - }, - { - "package": { - "ecosystem": "PyPI", - "name": "urllib3", - "purl": "pkg:pypi/urllib3" - }, - "ranges": [ - { - "type": "ECOSYSTEM", - "events": [ - { - "introduced": "0" - }, - { - "fixed": "1.26.18" - } - ] - } - ], - "versions": [ - "0.2", - "0.3", - "0.3.1", - "0.4.0", - "0.4.1", - "1.0", - "1.0.1", - "1.0.2", - "1.1", - "1.10", - "1.10.1", - "1.10.2", - "1.10.3", - "1.10.4", - "1.11", - "1.12", - "1.13", - "1.13.1", - "1.14", - "1.15", - "1.15.1", - "1.16", - "1.17", - "1.18", - "1.18.1", - "1.19", - "1.19.1", - "1.2", - "1.2.1", - "1.2.2", - "1.20", - "1.21", - "1.21.1", - "1.22", - "1.23", - "1.24", - "1.24.1", - "1.24.2", - "1.24.3", - "1.25", - "1.25.1", - "1.25.10", - "1.25.11", - "1.25.2", - "1.25.3", - "1.25.4", - "1.25.5", - "1.25.6", - "1.25.7", - "1.25.8", - "1.25.9", - "1.26.0", - "1.26.1", - "1.26.10", - "1.26.11", - "1.26.12", - "1.26.13", - "1.26.14", - "1.26.15", - "1.26.16", - "1.26.17", - "1.26.2", - "1.26.3", - "1.26.4", - "1.26.5", - "1.26.6", - "1.26.7", - "1.26.8", - "1.26.9", - "1.3", - "1.4", - "1.5", - "1.6", - "1.7", - "1.7.1", - "1.8", - "1.8.2", - "1.8.3", - "1.9", - "1.9.1" - ], - "database_specific": { - "source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2023/10/GHSA-g4mx-q9vg-27p4/GHSA-g4mx-q9vg-27p4.json" - } - } - ], - "severity": [ - { - "type": "CVSS_V3", - "score": "CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N" - } - ], - "references": [ - { - "type": "WEB", - "url": "https://github.com/urllib3/urllib3/security/advisories/GHSA-g4mx-q9vg-27p4" - }, - { - "type": "ADVISORY", - "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45803" - }, - { - "type": "WEB", - "url": "https://github.com/urllib3/urllib3/commit/4e50fbc5db74e32cabd5ccc1ab81fc103adfe0b3" - }, - { - "type": "WEB", - "url": "https://github.com/urllib3/urllib3/commit/4e98d57809dacab1cbe625fddeec1a290c478ea9" - }, - { - "type": "WEB", - "url": "https://github.com/urllib3/urllib3/commit/b594c5ceaca38e1ac215f916538fb128e3526a36" - }, - { - "type": "WEB", - "url": "https://github.com/pypa/advisory-database/tree/main/vulns/urllib3/PYSEC-2023-212.yaml" - }, - { - "type": "PACKAGE", - "url": "https://github.com/urllib3/urllib3" - }, - { - "type": "WEB", - "url": "https://github.com/urllib3/urllib3/releases/tag/1.26.18" - }, - { - "type": "WEB", - "url": "https://github.com/urllib3/urllib3/releases/tag/2.0.7" - }, - { - "type": "WEB", - "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4R2Y5XK3WALSR3FNAGN7JBYV2B343ZKB/" - }, - { - "type": "WEB", - "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5F5CUBAN5XMEBVBZPHFITBLMJV5FIJJ5/" - }, - { - "type": "WEB", - "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PPDPLM6UUMN55ESPQWJFLLIZY4ZKCNRX/" - }, - { - "type": "WEB", - "url": "https://www.rfc-editor.org/rfc/rfc9110.html#name-get" - } - ], - "database_specific": { - "cwe_ids": [ - "CWE-200" - ], - "github_reviewed": true, - "github_reviewed_at": "2023-10-17T20:15:25Z", - "nvd_published_at": "2023-10-17T20:15:10Z", - "severity": "MODERATE" - } - }, - { - "modified": "2023-11-04T00:48:52Z", - "published": "2023-10-02T23:27:05Z", - "schema_version": "1.6.0", - "id": "GHSA-v845-jxx5-vc9f", - "aliases": [ - "CVE-2023-43804" - ], - "summary": "`Cookie` HTTP header isn't stripped on cross-origin redirects", - "details": "urllib3 doesn't treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.\n\nUsers **must** handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the `Cookie` header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.\n\n## Affected usages\n\nWe believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:\n\n* Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)\n* Using the `Cookie` header on requests, which is mostly typical for impersonating a browser.\n* Not disabling HTTP redirects\n* Either not using HTTPS or for the origin server to redirect to a malicious origin.\n\n## Remediation\n\n* Upgrading to at least urllib3 v1.26.17 or v2.0.6\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Cookie` header.", - "affected": [ - { - "package": { - "ecosystem": "PyPI", - "name": "urllib3", - "purl": "pkg:pypi/urllib3" - }, - "ranges": [ - { - "type": "ECOSYSTEM", - "events": [ - { - "introduced": "2.0.0" - }, - { - "fixed": "2.0.6" - } - ] - } - ], - "versions": [ - "2.0.0", - "2.0.1", - "2.0.2", - "2.0.3", - "2.0.4", - "2.0.5" - ], - "database_specific": { - "source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2023/10/GHSA-v845-jxx5-vc9f/GHSA-v845-jxx5-vc9f.json" - } - }, - { - "package": { - "ecosystem": "PyPI", - "name": "urllib3", - "purl": "pkg:pypi/urllib3" - }, - "ranges": [ - { - "type": "ECOSYSTEM", - "events": [ - { - "introduced": "0" - }, - { - "fixed": "1.26.17" - } - ] - } - ], - "versions": [ - "0.2", - "0.3", - "0.3.1", - "0.4.0", - "0.4.1", - "1.0", - "1.0.1", - "1.0.2", - "1.1", - "1.10", - "1.10.1", - "1.10.2", - "1.10.3", - "1.10.4", - "1.11", - "1.12", - "1.13", - "1.13.1", - "1.14", - "1.15", - "1.15.1", - "1.16", - "1.17", - "1.18", - "1.18.1", - "1.19", - "1.19.1", - "1.2", - "1.2.1", - "1.2.2", - "1.20", - "1.21", - "1.21.1", - "1.22", - "1.23", - "1.24", - "1.24.1", - "1.24.2", - "1.24.3", - "1.25", - "1.25.1", - "1.25.10", - "1.25.11", - "1.25.2", - "1.25.3", - "1.25.4", - "1.25.5", - "1.25.6", - "1.25.7", - "1.25.8", - "1.25.9", - "1.26.0", - "1.26.1", - "1.26.10", - "1.26.11", - "1.26.12", - "1.26.13", - "1.26.14", - "1.26.15", - "1.26.16", - "1.26.2", - "1.26.3", - "1.26.4", - "1.26.5", - "1.26.6", - "1.26.7", - "1.26.8", - "1.26.9", - "1.3", - "1.4", - "1.5", - "1.6", - "1.7", - "1.7.1", - "1.8", - "1.8.2", - "1.8.3", - "1.9", - "1.9.1" - ], - "database_specific": { - "source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2023/10/GHSA-v845-jxx5-vc9f/GHSA-v845-jxx5-vc9f.json" - } - } - ], - "severity": [ - { - "type": "CVSS_V3", - "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N" - } - ], - "references": [ - { - "type": "WEB", - "url": "https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f" - }, - { - "type": "ADVISORY", - "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43804" - }, - { - "type": "WEB", - "url": "https://github.com/urllib3/urllib3/commit/01220354d389cd05474713f8c982d05c9b17aafb" - }, - { - "type": "WEB", - "url": "https://github.com/urllib3/urllib3/commit/644124ecd0b6e417c527191f866daa05a5a2056d" - }, - { - "type": "WEB", - "url": "https://github.com/pypa/advisory-database/tree/main/vulns/urllib3/PYSEC-2023-192.yaml" - }, - { - "type": "PACKAGE", - "url": "https://github.com/urllib3/urllib3" - }, - { - "type": "WEB", - "url": "https://lists.debian.org/debian-lts-announce/2023/10/msg00012.html" - }, - { - "type": "WEB", - "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5F5CUBAN5XMEBVBZPHFITBLMJV5FIJJ5/" - }, - { - "type": "WEB", - "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/I3PR7C6RJ6JUBQKIJ644DMIJSUP36VDY/" - }, - { - "type": "WEB", - "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NDAGZXYJ7H2G3SB47M453VQVNAWKAEJJ/" - } - ], - "database_specific": { - "cwe_ids": [ - "CWE-200" - ], - "github_reviewed": true, - "github_reviewed_at": "2023-10-02T23:27:05Z", - "nvd_published_at": "2023-10-04T17:15:10Z", - "severity": "MODERATE" - } - }, - { - "modified": "2023-10-10T14:28:19Z", - "published": "2023-10-04T17:15:00Z", - "schema_version": "1.6.0", - "id": "PYSEC-2023-192", - "aliases": [ - "CVE-2023-43804", - "GHSA-v845-jxx5-vc9f" - ], - "details": "urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn't treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. This issue has been patched in urllib3 version 1.26.17 or 2.0.5.", - "affected": [ - { - "package": { - "ecosystem": "PyPI", - "name": "urllib3", - "purl": "pkg:pypi/urllib3" - }, - "ranges": [ - { - "type": "GIT", - "events": [ - { - "introduced": "0" - }, - { - "fixed": "644124ecd0b6e417c527191f866daa05a5a2056d" - }, - { - "fixed": "01220354d389cd05474713f8c982d05c9b17aafb" - } - ], - "repo": "https://github.com/urllib3/urllib3" - }, - { - "type": "ECOSYSTEM", - "events": [ - { - "introduced": "2.0.0" - }, - { - "fixed": "2.0.6" - }, - { - "introduced": "0" - }, - { - "fixed": "1.26.17" - } - ] - } - ], - "versions": [ - "0.2", - "0.3", - "0.3.1", - "0.4.0", - "0.4.1", - "1.0", - "1.0.1", - "1.0.2", - "1.1", - "1.10", - "1.10.1", - "1.10.2", - "1.10.3", - "1.10.4", - "1.11", - "1.12", - "1.13", - "1.13.1", - "1.14", - "1.15", - "1.15.1", - "1.16", - "1.17", - "1.18", - "1.18.1", - "1.19", - "1.19.1", - "1.2", - "1.2.1", - "1.2.2", - "1.20", - "1.21", - "1.21.1", - "1.22", - "1.23", - "1.24", - "1.24.1", - "1.24.2", - "1.24.3", - "1.25", - "1.25.1", - "1.25.10", - "1.25.11", - "1.25.2", - "1.25.3", - "1.25.4", - "1.25.5", - "1.25.6", - "1.25.7", - "1.25.8", - "1.25.9", - "1.26.0", - "1.26.1", - "1.26.10", - "1.26.11", - "1.26.12", - "1.26.13", - "1.26.14", - "1.26.15", - "1.26.16", - "1.26.2", - "1.26.3", - "1.26.4", - "1.26.5", - "1.26.6", - "1.26.7", - "1.26.8", - "1.26.9", - "1.3", - "1.4", - "1.5", - "1.6", - "1.7", - "1.7.1", - "1.8", - "1.8.2", - "1.8.3", - "1.9", - "1.9.1", - "2.0.0", - "2.0.1", - "2.0.2", - "2.0.3", - "2.0.4", - "2.0.5" - ], - "database_specific": { - "source": "https://github.com/pypa/advisory-database/blob/main/vulns/urllib3/PYSEC-2023-192.yaml" - } - } - ], - "severity": [ - { - "type": "CVSS_V3", - "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N" - } - ], - "references": [ - { - "type": "FIX", - "url": "https://github.com/urllib3/urllib3/commit/644124ecd0b6e417c527191f866daa05a5a2056d" - }, - { - "type": "ADVISORY", - "url": "https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f" - }, - { - "type": "FIX", - "url": "https://github.com/urllib3/urllib3/commit/01220354d389cd05474713f8c982d05c9b17aafb" - }, - { - "type": "WEB", - "url": "https://lists.debian.org/debian-lts-announce/2023/10/msg00012.html" - } - ] - }, - { - "modified": "2023-10-25T18:28:34Z", - "published": "2023-10-17T20:15:00Z", - "schema_version": "1.6.0", - "id": "PYSEC-2023-212", - "aliases": [ - "CVE-2023-45803", - "GHSA-g4mx-q9vg-27p4" - ], - "details": "urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable redirects for services that aren't expecting to respond with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.\n", - "affected": [ - { - "package": { - "ecosystem": "PyPI", - "name": "urllib3", - "purl": "pkg:pypi/urllib3" - }, - "ranges": [ - { - "type": "GIT", - "events": [ - { - "introduced": "0" - }, - { - "fixed": "4e98d57809dacab1cbe625fddeec1a290c478ea9" - } - ], - "repo": "https://github.com/urllib3/urllib3" - }, - { - "type": "ECOSYSTEM", - "events": [ - { - "introduced": "2.0.0" - }, - { - "fixed": "2.0.7" - }, - { - "introduced": "0" - }, - { - "fixed": "1.26.18" - } - ] - } - ], - "versions": [ - "0.2", - "0.3", - "0.3.1", - "0.4.0", - "0.4.1", - "1.0", - "1.0.1", - "1.0.2", - "1.1", - "1.10", - "1.10.1", - "1.10.2", - "1.10.3", - "1.10.4", - "1.11", - "1.12", - "1.13", - "1.13.1", - "1.14", - "1.15", - "1.15.1", - "1.16", - "1.17", - "1.18", - "1.18.1", - "1.19", - "1.19.1", - "1.2", - "1.2.1", - "1.2.2", - "1.20", - "1.21", - "1.21.1", - "1.22", - "1.23", - "1.24", - "1.24.1", - "1.24.2", - "1.24.3", - "1.25", - "1.25.1", - "1.25.10", - "1.25.11", - "1.25.2", - "1.25.3", - "1.25.4", - "1.25.5", - "1.25.6", - "1.25.7", - "1.25.8", - "1.25.9", - "1.26.0", - "1.26.1", - "1.26.10", - "1.26.11", - "1.26.12", - "1.26.13", - "1.26.14", - "1.26.15", - "1.26.16", - "1.26.17", - "1.26.2", - "1.26.3", - "1.26.4", - "1.26.5", - "1.26.6", - "1.26.7", - "1.26.8", - "1.26.9", - "1.3", - "1.4", - "1.5", - "1.6", - "1.7", - "1.7.1", - "1.8", - "1.8.2", - "1.8.3", - "1.9", - "1.9.1", - "2.0.0", - "2.0.1", - "2.0.2", - "2.0.3", - "2.0.4", - "2.0.5", - "2.0.6" - ], - "database_specific": { - "source": "https://github.com/pypa/advisory-database/blob/main/vulns/urllib3/PYSEC-2023-212.yaml" - } - } - ], - "severity": [ - { - "type": "CVSS_V3", - "score": "CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N" - } - ], - "references": [ - { - "type": "ADVISORY", - "url": "https://github.com/urllib3/urllib3/security/advisories/GHSA-g4mx-q9vg-27p4" - }, - { - "type": "WEB", - "url": "https://www.rfc-editor.org/rfc/rfc9110.html#name-get" - }, - { - "type": "FIX", - "url": "https://github.com/urllib3/urllib3/commit/4e98d57809dacab1cbe625fddeec1a290c478ea9" - }, - { - "type": "ARTICLE", - "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PPDPLM6UUMN55ESPQWJFLLIZY4ZKCNRX/" - } - ] - } - ], - "groups": [ - { - "ids": [ - "GHSA-g4mx-q9vg-27p4", - "PYSEC-2023-212" - ] - }, - { - "ids": [ - "GHSA-v845-jxx5-vc9f", - "PYSEC-2023-192" - ] - } - ] - } -] \ No newline at end of file diff --git a/audits/scrapy-requirements.audit.json b/audits/scrapy-requirements.audit.json index b3db3ce7..b75e4447 100644 --- a/audits/scrapy-requirements.audit.json +++ b/audits/scrapy-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T16:01:50Z", + "modified": "2023-11-08T04:13:41Z", "published": "2023-10-25T21:15:13Z", "schema_version": "1.6.0", "id": "GHSA-xc8x-vp79-p3wm", "aliases": [ - "CVE-2023-46137" + "CVE-2023-46137", + "PYSEC-2023-224" ], "summary": "twisted.web has disordered HTTP pipeline response", "details": "Twisted is an event-based framework for internet applications. Prior to version 23.10.0rc1, when sending multiple HTTP requests in one TCP packet, twisted.web will process the requests asynchronously without guaranteeing the response order. If one of the endpoints is controlled by an attacker, the attacker can delay the response on purpose to manipulate the response of the second request when a victim launched two requests using HTTP pipeline. Version 23.10.0rc1 contains a patch for this issue.\n\n### Details\nThere's an example faulty program:\n```python\nfrom twisted.internet import reactor, endpoints\nfrom twisted.web import server\nfrom twisted.web.proxy import ReverseProxyResource\nfrom twisted.web.resource import Resource\n\nclass Second(Resource):\n isLeaf = True\n def render_GET(self, request):\n return b'SECOND\\n'\n\nclass First(Resource):\n isLeaf = True\n def render_GET(self, request):\n def send_response():\n request.write(b'FIRST DELAYED\\n')\n request.finish()\n reactor.callLater(0.5, send_response)\n return server.NOT_DONE_YET\n\nroot = Resource()\n\nroot.putChild(b'second', Second())\nroot.putChild(b'first', First())\n\nendpoint = endpoints.TCP4ServerEndpoint(reactor, 8080)\nendpoint.listen(server.Site(root))\nreactor.run()\n```\n\nWhen two requests for `/first` and `/second` are sent in the same order, the second request will be responded to first.\n```shell\necho -en \"GET /first HTTP/1.1\\r\\nHost: a\\r\\n\\r\\nGET /second HTTP/1.1\\r\\nHost: a\\r\\n\\r\\n\" | nc localhost 8080\n```", @@ -174,7 +175,7 @@ } }, { - "modified": "2023-11-02T16:33:16Z", + "modified": "2023-11-08T04:13:41Z", "published": "2023-10-25T21:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-224", diff --git a/audits/sickchill-requirements.audit.json b/audits/sickchill-requirements.audit.json index 43303ad0..bf338647 100644 --- a/audits/sickchill-requirements.audit.json +++ b/audits/sickchill-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", diff --git a/audits/snapcraft-requirements.audit.json b/audits/snapcraft-requirements.audit.json index 034b2655..db45ff8f 100644 --- a/audits/snapcraft-requirements.audit.json +++ b/audits/snapcraft-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -227,12 +228,13 @@ } }, { - "modified": "2023-11-04T00:48:52Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-02T23:27:05Z", "schema_version": "1.6.0", "id": "GHSA-v845-jxx5-vc9f", "aliases": [ - "CVE-2023-43804" + "CVE-2023-43804", + "PYSEC-2023-192" ], "summary": "`Cookie` HTTP header isn't stripped on cross-origin redirects", "details": "urllib3 doesn't treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.\n\nUsers **must** handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the `Cookie` header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.\n\n## Affected usages\n\nWe believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:\n\n* Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)\n* Using the `Cookie` header on requests, which is mostly typical for impersonating a browser.\n* Not disabling HTTP redirects\n* Either not using HTTPS or for the origin server to redirect to a malicious origin.\n\n## Remediation\n\n* Upgrading to at least urllib3 v1.26.17 or v2.0.6\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Cookie` header.", @@ -432,7 +434,7 @@ } }, { - "modified": "2023-10-10T14:28:19Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-04T17:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-192", @@ -600,7 +602,7 @@ ] }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", diff --git a/audits/terminator-requirements.audit.json b/audits/terminator-requirements.audit.json index 43303ad0..bf338647 100644 --- a/audits/terminator-requirements.audit.json +++ b/audits/terminator-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", diff --git a/audits/tern-requirements.audit.json b/audits/tern-requirements.audit.json index d952fa91..542a91f9 100644 --- a/audits/tern-requirements.audit.json +++ b/audits/tern-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-05T05:24:11Z", + "modified": "2023-11-08T04:13:23Z", "published": "2023-08-30T20:09:36Z", "schema_version": "1.6.0", "id": "GHSA-cwvm-v4w8-q58c", "aliases": [ - "CVE-2023-41040" + "CVE-2023-41040", + "PYSEC-2023-165" ], "summary": "Blind local file inclusion", "details": "### Summary\n\nIn 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.\n\n### Details\n\nThis vulnerability is present in\n\nhttps://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/refs/symbolic.py#L174-L175\n\nThat code joins the base directory with a user given string without checking if the final path is located outside the base directory.\n\nI was able to exploit it from three places, but there may be more code paths that lead to it:\n\nhttps://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/repo/base.py#L605\n\nhttps://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/repo/base.py#L620\n\nhttps://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/index/base.py#L1353\n\n### PoC\n\nRunning GitPython within any repo should work, here is an example with the GitPython repo.\n\n```python\nimport git\n\nr = git.Repo(\".\")\n\n# This will make GitPython read the README.md file from the root of the repo\nr.commit(\"../README.md\")\nr.tree(\"../README.md\")\nr.index.diff(\"../README.md\")\n\n# Reading /etc/random\n# WARNING: this will probably halt your system, run with caution\n# r.commit(\"../../../../../../../../../dev/random\")\n```\n\n### Impact\n\nI wasn't able to show the contents of the files (that's why \"blind\" local file inclusion), depending on how GitPython is being used, this can be used by an attacker for something _inoffensive_ as checking if a file exits, or cause a DoS by making GitPython read a big/infinite file (like `/dev/random` on Linux systems).\n\n### Possible solutions\n\nA solution would be to check that the final path isn't located outside the `repodir` path (maybe even after resolving symlinks). Maybe there could be other checks in place to make sure that the reference names are valid.\n\n---\n\n> [!NOTE]\n> This vulnerability was reported via email, and it was decided to publish it here and make it public, so the community is aware of it, and a fix can be provided.", @@ -190,12 +191,13 @@ } }, { - "modified": "2023-11-05T05:27:28Z", + "modified": "2023-11-08T04:13:22Z", "published": "2023-08-29T23:33:53Z", "schema_version": "1.6.0", "id": "GHSA-wfm5-v35h-vwf4", "aliases": [ - "CVE-2023-40590" + "CVE-2023-40590", + "PYSEC-2023-161" ], "summary": "GitPython untrusted search path on Windows systems leading to arbitrary code execution", "details": "### Summary\n\nWhen resolving a program, Python/Windows look for the current working directory, and after that the PATH environment (see big warning in https://docs.python.org/3/library/subprocess.html#popen-constructor). 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`.\n\n### Details\n\nThis 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.\n\nThe execution of the `git` command happens in\n\nhttps://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/cmd.py#L277 \n\nhttps://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/cmd.py#L983-L996\n\nAnd there are other commands executed that should probably be aware of this problem.\n\n### PoC\n\nOn a Windows system, create a `git.exe` or `git` executable in any directory, and import or run GitPython from that directory\n\n```\npython -c \"import git\"\n```\n\nThe git executable from the current directory will be run.\n\n### Impact\n\nAn 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.\n\n### Possible solutions\n \n- Default to an absolute path for the git program on Windows, like `C:\\\\Program Files\\\\Git\\\\cmd\\\\git.EXE` (default git path installation).\n- Require users to set the `GIT_PYTHON_GIT_EXECUTABLE` environment variable on Windows systems.\n- 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.\n- Resolve the executable manually by only looking into the `PATH` environment variable (suggested by @Byron)\n\n---\n\n> [!NOTE]\n> This vulnerability was reported via email, and it was decided to publish it here and make it public, so the community is aware of it, and a fix can be provided.", @@ -368,7 +370,7 @@ } }, { - "modified": "2023-09-05T22:26:14Z", + "modified": "2023-11-08T04:13:22Z", "published": "2023-08-28T18:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-161", @@ -508,7 +510,7 @@ ] }, { - "modified": "2023-09-07T14:33:25Z", + "modified": "2023-11-08T04:13:23Z", "published": "2023-08-30T22:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-165", @@ -674,12 +676,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -893,12 +896,13 @@ } }, { - "modified": "2023-11-04T00:48:52Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-02T23:27:05Z", "schema_version": "1.6.0", "id": "GHSA-v845-jxx5-vc9f", "aliases": [ - "CVE-2023-43804" + "CVE-2023-43804", + "PYSEC-2023-192" ], "summary": "`Cookie` HTTP header isn't stripped on cross-origin redirects", "details": "urllib3 doesn't treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.\n\nUsers **must** handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the `Cookie` header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.\n\n## Affected usages\n\nWe believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:\n\n* Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)\n* Using the `Cookie` header on requests, which is mostly typical for impersonating a browser.\n* Not disabling HTTP redirects\n* Either not using HTTPS or for the origin server to redirect to a malicious origin.\n\n## Remediation\n\n* Upgrading to at least urllib3 v1.26.17 or v2.0.6\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Cookie` header.", @@ -1098,7 +1102,7 @@ } }, { - "modified": "2023-10-10T14:28:19Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-04T17:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-192", @@ -1266,7 +1270,7 @@ ] }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", diff --git a/audits/theharvester-requirements.audit.json b/audits/theharvester-requirements.audit.json index 034b2655..db45ff8f 100644 --- a/audits/theharvester-requirements.audit.json +++ b/audits/theharvester-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -227,12 +228,13 @@ } }, { - "modified": "2023-11-04T00:48:52Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-02T23:27:05Z", "schema_version": "1.6.0", "id": "GHSA-v845-jxx5-vc9f", "aliases": [ - "CVE-2023-43804" + "CVE-2023-43804", + "PYSEC-2023-192" ], "summary": "`Cookie` HTTP header isn't stripped on cross-origin redirects", "details": "urllib3 doesn't treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.\n\nUsers **must** handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the `Cookie` header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.\n\n## Affected usages\n\nWe believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:\n\n* Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)\n* Using the `Cookie` header on requests, which is mostly typical for impersonating a browser.\n* Not disabling HTTP redirects\n* Either not using HTTPS or for the origin server to redirect to a malicious origin.\n\n## Remediation\n\n* Upgrading to at least urllib3 v1.26.17 or v2.0.6\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Cookie` header.", @@ -432,7 +434,7 @@ } }, { - "modified": "2023-10-10T14:28:19Z", + "modified": "2023-11-08T04:13:33Z", "published": "2023-10-04T17:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-192", @@ -600,7 +602,7 @@ ] }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", diff --git a/audits/torchvision-requirements.audit.json b/audits/torchvision-requirements.audit.json index aaee1072..73194a85 100644 --- a/audits/torchvision-requirements.audit.json +++ b/audits/torchvision-requirements.audit.json @@ -8,12 +8,13 @@ }, "vulnerabilities": [ { - "modified": "2023-11-06T16:43:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:25Z", "schema_version": "1.6.0", "id": "GHSA-g4mx-q9vg-27p4", "aliases": [ - "CVE-2023-45803" + "CVE-2023-45803", + "PYSEC-2023-212" ], "summary": "urllib3's request body not stripped after redirect from 303 status changes request method to GET", "details": "urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 \"See Other\" after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.\n\nFrom [RFC 9110 Section 9.3.1](https://www.rfc-editor.org/rfc/rfc9110.html#name-get):\n\n> A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.\n\n## Affected usages\n\nBecause the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.\n\nBoth of the following conditions must be true to be affected by this vulnerability:\n\n* If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)\n* The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.\n\n## Remediation\n\nYou can remediate this vulnerability with any of the following steps:\n\n* Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)\n* Disable redirects for services that you aren't expecting to respond with redirects with `redirects=False`.\n* Disable automatic redirects with `redirects=False` and handle 303 redirects manually by stripping the HTTP request body.\n", @@ -227,7 +228,7 @@ } }, { - "modified": "2023-10-25T18:28:34Z", + "modified": "2023-11-08T04:13:39Z", "published": "2023-10-17T20:15:00Z", "schema_version": "1.6.0", "id": "PYSEC-2023-212", diff --git a/audits/twarc-requirements.audit.json b/audits/twarc-requirements.audit.json index 43303ad0..bf338647 100644 --- a/audits/twarc-requirements.audit.json +++ b/audits/twarc-requirements.audit.json @@ -8,7 +8,7 @@ }, "vulnerabilities": [ { - "modified": "2023-11-03T21:48:20Z", + "modified": "2023-11-08T04:11:58Z", "published": "2023-04-03T06:30:19Z", "schema_version": "1.6.0", "id": "GHSA-c33w-24p9-8m24", diff --git a/requirements/asitop-requirements.txt b/requirements/asitop-requirements.txt new file mode 100644 index 00000000..8d4e41b6 --- /dev/null +++ b/requirements/asitop-requirements.txt @@ -0,0 +1,3 @@ +blessed==1.20.0 +dashing==0.1.0 +wcwidth==0.2.10 diff --git a/requirements/aws-sam-cli-requirements.txt b/requirements/aws-sam-cli-requirements.txt index 6392c8bd..8aad2bb7 100644 --- a/requirements/aws-sam-cli-requirements.txt +++ b/requirements/aws-sam-cli-requirements.txt @@ -1,15 +1,15 @@ annotated-types==0.6.0 arrow==1.3.0 attrs==23.1.0 -aws-lambda-builders==1.40.0 +aws-lambda-builders==1.41.0 aws-sam-translator==1.79.0 binaryornot==0.4.4 blinker==1.7.0 -boto3==1.28.83 +boto3==1.29.0 boto3-stubs==1.28.80 -botocore==1.31.83 -botocore-stubs==1.31.83 -cfn-lint==0.83.1 +botocore==1.32.0 +botocore-stubs==1.32.0 +cfn-lint==0.83.2 chardet==5.2.0 charset-normalizer==3.3.2 chevron==0.14.0 @@ -27,7 +27,7 @@ jsonpatch==1.33 jsonpickle==3.0.2 jsonpointer==2.4 jsonschema==4.19.2 -jsonschema-specifications==2023.7.1 +jsonschema-specifications==2023.11.1 junit-xml==1.9 markdown-it-py==3.0.0 markupsafe==2.1.3 @@ -49,12 +49,12 @@ mypy-boto3-sts==1.28.58 mypy-boto3-xray==1.28.64 networkx==3.2.1 pbr==6.0.0 -pydantic==2.4.2 -pydantic-core==2.10.1 +pydantic==2.5.0 +pydantic-core==2.14.1 pyopenssl==23.3.0 python-dateutil==2.8.2 python-slugify==8.0.1 -referencing==0.30.2 +referencing==0.31.0 regex==2023.10.3 requests==2.31.0 rich==13.6.0 @@ -66,7 +66,7 @@ sarif-om==1.0.4 sympy==1.12 text-unidecode==1.3 tomlkit==0.12.2 -types-awscrt==0.19.9 +types-awscrt==0.19.12 types-python-dateutil==2.8.19.14 types-s3transfer==0.7.0 tzlocal==5.2 diff --git a/requirements/awscli@1-requirements.txt b/requirements/awscli@1-requirements.txt index 97349fe4..3592142e 100644 --- a/requirements/awscli@1-requirements.txt +++ b/requirements/awscli@1-requirements.txt @@ -1,4 +1,4 @@ -botocore==1.31.80 +botocore==1.32.0 colorama==0.4.4 jmespath==1.0.1 pyasn1==0.5.0 diff --git a/requirements/conan-requirements.txt b/requirements/conan-requirements.txt index 62a86670..4e8fc617 100644 --- a/requirements/conan-requirements.txt +++ b/requirements/conan-requirements.txt @@ -1,4 +1,4 @@ -charset-normalizer==3.3.0 +charset-normalizer==3.3.2 colorama==0.4.6 distro==1.8.0 fasteners==0.19 diff --git a/requirements/conan@1-requirements.txt b/requirements/conan@1-requirements.txt index e8499b19..426ece44 100644 --- a/requirements/conan@1-requirements.txt +++ b/requirements/conan@1-requirements.txt @@ -1,5 +1,5 @@ bottle==0.12.25 -charset-normalizer==3.3.1 +charset-normalizer==3.3.2 colorama==0.4.6 distro==1.8.0 fasteners==0.19 diff --git a/requirements/dvc-requirements.txt b/requirements/dvc-requirements.txt index b5187f08..1653e36a 100644 --- a/requirements/dvc-requirements.txt +++ b/requirements/dvc-requirements.txt @@ -24,7 +24,7 @@ billiard==4.2.0 boto3==1.28.17 botocore==1.31.17 cachetools==5.3.2 -celery==5.3.4 +celery==5.3.5 charset-normalizer==3.3.2 click-didyoumean==0.3.0 click-plugins==1.1.1 @@ -76,7 +76,7 @@ googleapis-common-protos==1.61.0 grandalf==0.8 gto==1.5.0 h11==0.14.0 -httpcore==1.0.1 +httpcore==1.0.2 httplib2==0.22.0 httpx==0.25.1 hydra-core==1.3.2 @@ -101,12 +101,12 @@ ossfs==2021.8.0 pathspec==0.11.2 platformdirs==3.11.0 portalocker==2.8.2 -prompt-toolkit==3.0.39 +prompt-toolkit==3.0.41 pyasn1==0.5.0 pyasn1-modules==0.3.0 pycryptodome==3.19.0 -pydantic==2.4.2 -pydantic-core==2.10.1 +pydantic==2.5.0 +pydantic-core==2.14.1 pydot==1.4.2 pydrive2==1.17.0 pygtrie==2.5.0 @@ -121,7 +121,7 @@ ruamel-yaml==0.18.5 ruamel-yaml-clib==0.2.8 s3fs==2023.9.2 s3transfer==0.6.2 -scmrepo==1.4.0 +scmrepo==1.4.1 semver==3.0.2 shortuuid==1.0.11 shtab==1.6.4 @@ -136,8 +136,8 @@ tzdata==2023.3 uritemplate==4.1.1 urllib3==1.26.18 vine==5.1.0 -voluptuous==0.13.1 -wcwidth==0.2.9 +voluptuous==0.14.0 +wcwidth==0.2.10 webdav4==0.9.8 wrapt==1.16.0 yarl==1.9.2 diff --git a/requirements/oci-cli-requirements.txt b/requirements/oci-cli-requirements.txt index c247e9c1..8a086a27 100644 --- a/requirements/oci-cli-requirements.txt +++ b/requirements/oci-cli-requirements.txt @@ -1,10 +1,10 @@ arrow==1.3.0 circuitbreaker==1.4.0 jmespath==0.10.0 -oci==2.115.1 +oci==2.116.0 prompt-toolkit==3.0.29 pyopenssl==23.3.0 python-dateutil==2.8.2 terminaltables==3.1.0 types-python-dateutil==2.8.19.14 -wcwidth==0.2.9 +wcwidth==0.2.10 diff --git a/requirements/pipenv-requirements.txt b/requirements/pipenv-requirements.txt new file mode 100644 index 00000000..1040a75b --- /dev/null +++ b/requirements/pipenv-requirements.txt @@ -0,0 +1,4 @@ +distlib==0.3.7 +filelock==3.13.1 +platformdirs==3.11.0 +virtualenv==20.24.6 diff --git a/requirements/pwntools-requirements.txt b/requirements/pwntools-requirements.txt index 811010b5..b5d0af22 100644 --- a/requirements/pwntools-requirements.txt +++ b/requirements/pwntools-requirements.txt @@ -1,6 +1,6 @@ bcrypt==4.0.1 capstone==5.0.1 -charset-normalizer==3.3.0 +charset-normalizer==3.3.2 colored-traceback==0.3.0 idna==3.4 intervaltree==3.1.0 @@ -16,4 +16,4 @@ ropgadget==7.4 rpyc==5.3.1 sortedcontainers==2.4.0 unicorn==2.0.1.post1 -urllib3==2.0.7 +urllib3==2.1.0 diff --git a/requirements/scoutsuite-requirements.txt b/requirements/scoutsuite-requirements.txt index abfc4f8c..e0b76354 100644 --- a/requirements/scoutsuite-requirements.txt +++ b/requirements/scoutsuite-requirements.txt @@ -1,17 +1,17 @@ aliyun-python-sdk-actiontrail==2.2.0 aliyun-python-sdk-core==2.14.0 -aliyun-python-sdk-ecs==4.24.66 +aliyun-python-sdk-ecs==4.24.68 aliyun-python-sdk-kms==2.16.2 aliyun-python-sdk-ocs==0.0.4 aliyun-python-sdk-ram==3.3.0 aliyun-python-sdk-rds==2.7.43 -aliyun-python-sdk-sts==3.1.1 +aliyun-python-sdk-sts==3.1.2 aliyun-python-sdk-vpc==3.0.45 -annotated-types==0.5.0 +annotated-types==0.6.0 asyncio-throttle==1.0.2 autocommand==2.2.2 azure-common==1.1.28 -azure-core==1.29.4 +azure-core==1.29.5 azure-identity==1.5.0 azure-mgmt-authorization==3.0.0 azure-mgmt-compute==18.2.0 @@ -26,35 +26,35 @@ azure-mgmt-security==1.0.0 azure-mgmt-sql==1.0.0 azure-mgmt-storage==16.0.0 azure-mgmt-web==1.0.0 -boto3==1.28.56 -botocore==1.31.56 -cachetools==5.3.1 -charset-normalizer==3.2.0 +boto3==1.29.0 +botocore==1.32.0 +cachetools==5.3.2 +charset-normalizer==3.3.2 cheroot==10.0.0 -CherryPy==18.8.0 +cherrypy==18.8.0 cherrypy-cors==1.7.0 circuitbreaker==1.4.0 coloredlogs==10.0 crcmod==1.7 google-api-core==1.34.0 -google-api-python-client==2.101.0 -google-auth==2.23.0 +google-api-python-client==2.108.0 +google-auth==2.23.4 google-auth-httplib2==0.1.1 -google-cloud-appengine-logging==1.3.1 +google-cloud-appengine-logging==1.3.2 google-cloud-audit-log==0.2.5 -google-cloud-container==2.31.0 +google-cloud-container==2.33.0 google-cloud-core==2.3.3 google-cloud-iam==2.12.2 google-cloud-kms==1.3.0 -google-cloud-logging==3.7.0 +google-cloud-logging==3.8.0 google-cloud-monitoring==1.1.0 google-cloud-resource-manager==1.10.4 -google-cloud-storage==2.11.0 +google-cloud-storage==2.13.0 google-crc32c==1.5.0 google-resumable-media==2.6.0 -googleapis-common-protos==1.60.0 -grpc-google-iam-v1==0.12.6 -grpcio==1.58.0 +googleapis-common-protos==1.61.0 +grpc-google-iam-v1==0.12.7 +grpcio==1.59.2 grpcio-status==1.48.2 httpagentparser==1.9.5 httplib2==0.22.0 @@ -65,20 +65,20 @@ inflect==7.0.0 isodate==0.6.1 jaraco-collections==4.3.0 jaraco-context==4.3.0 -jaraco-functools==3.9.0 +jaraco-functools==4.0.0 jaraco-text==3.11.1 jmespath==0.10.0 kubernetes==28.1.0 more-itertools==10.1.0 -msal==1.24.0 +msal==1.25.0 msal-extensions==0.3.1 msgraph-core==0.2.2 msrest==0.7.1 netaddr==0.9.0 oauth2client==4.1.3 oauthlib==3.2.2 -oci==2.112.2 -oss2==2.18.2 +oci==2.116.0 +oss2==2.18.3 policyuniverse==1.5.1.20230817 portalocker==2.8.2 portend==3.2.0 @@ -87,10 +87,10 @@ protobuf==3.20.3 pyasn1==0.5.0 pyasn1-modules==0.3.0 pycryptodome==3.19.0 -pydantic==2.4.2 -pydantic-core==2.10.1 -PyJWT==2.8.0 -pyOpenSSL==23.2.0 +pydantic==2.5.0 +pydantic-core==2.14.1 +pyjwt==2.8.0 +pyopenssl==23.3.0 python-dateutil==2.8.0 requests==2.31.0 requests-oauthlib==1.3.1 @@ -99,6 +99,6 @@ s3transfer==0.7.0 sqlitedict==2.1.0 tempora==5.5.0 uritemplate==4.1.1 -urllib3==1.26.16 -websocket-client==1.6.3 +urllib3==1.26.18 +websocket-client==1.6.4 zc-lockfile==3.0.post1 diff --git a/requirements/sigma-cli-requirements.txt b/requirements/sigma-cli-requirements.txt index 2678fd38..c5448f2e 100644 --- a/requirements/sigma-cli-requirements.txt +++ b/requirements/sigma-cli-requirements.txt @@ -4,8 +4,8 @@ idna==3.4 jinja2==3.1.2 packaging==22.0 prettytable==3.9.0 -pysigma==0.10.6 +pysigma==0.10.8 pysigma-backend-sqlite==0.1.0 requests==2.31.0 -urllib3==2.0.7 -wcwidth==0.2.9 +urllib3==2.1.0 +wcwidth==0.2.10 diff --git a/requirements/thefuck-requirements.txt b/requirements/thefuck-requirements.txt index 41d7110a..935526e5 100644 --- a/requirements/thefuck-requirements.txt +++ b/requirements/thefuck-requirements.txt @@ -1,5 +1,5 @@ colorama==0.4.6 decorator==5.1.1 -psutil==5.9.3 -pyte==0.8.1 -wcwidth==0.2.5 +psutil==5.9.6 +pyte==0.8.2 +wcwidth==0.2.10 diff --git a/requirements/yt-dlp-requirements.txt b/requirements/yt-dlp-requirements.txt index b06f4f3a..38ca38c3 100644 --- a/requirements/yt-dlp-requirements.txt +++ b/requirements/yt-dlp-requirements.txt @@ -1,3 +1,7 @@ brotli==1.1.0 +charset-normalizer==3.3.2 +idna==3.4 pycryptodomex==3.19.0 -websockets==11.0.3 +requests==2.31.0 +urllib3==2.1.0 +websockets==12.0 diff --git a/requirements/zurl-requirements.txt b/requirements/zurl-requirements.txt index 1085a114..c28f0274 100644 --- a/requirements/zurl-requirements.txt +++ b/requirements/zurl-requirements.txt @@ -1 +1 @@ -pyzmq==24.0.1 +pyzmq==25.1.1