diff --git a/audits/animdl-requirements.audit.json b/audits/animdl-requirements.audit.json index a8ea1274..d2722891 100644 --- a/audits/animdl-requirements.audit.json +++ b/audits/animdl-requirements.audit.json @@ -356,7 +356,8 @@ ], "related": [ "CGA-5g34-q98x-rv72", - "CGA-wprj-p696-fg4q" + "CGA-wprj-p696-fg4q", + "CVE-2024-34062" ], "summary": "tqdm CLI arguments injection attack", "details": "### Impact\nAny optional non-boolean CLI arguments (e.g. `--delim`, `--buf-size`, `--manpath`) are passed through python's `eval`, allowing arbitrary code execution. Example:\n\n```sh\npython -m tqdm --manpath=\"\\\" + str(exec(\\\"import os\\nos.system('echo hi && killall python3')\\\")) + \\\"\"\n```\n\n### Patches\nhttps://github.com/tqdm/tqdm/commit/4e613f84ed2ae029559f539464df83fa91feb316 released in `tqdm>=4.66.3`\n\n### Workarounds\nNone\n\n### References\n- https://github.com/tqdm/tqdm/releases/tag/v4.66.3", diff --git a/audits/athenacli-requirements.audit.json b/audits/athenacli-requirements.audit.json index 2a7eba69..becfc462 100644 --- a/audits/athenacli-requirements.audit.json +++ b/audits/athenacli-requirements.audit.json @@ -314,7 +314,8 @@ ], "related": [ "CGA-p7rq-qffc-ch9v", - "CGA-v3hx-x533-rpgf" + "CGA-v3hx-x533-rpgf", + "CVE-2024-4340" ], "summary": "sqlparse parsing heavily nested list leads to Denial of Service", "details": "### Summary\nPassing a heavily nested list to sqlparse.parse() leads to a Denial of Service due to RecursionError.\n\n### Details + PoC\nRunning the following code will raise Maximum recursion limit exceeded exception:\n```py\nimport sqlparse\nsqlparse.parse('[' * 10000 + ']' * 10000)\n```\nWe expect a traceback of RecursionError:\n```py\nTraceback (most recent call last):\n File \"trigger_sqlparse_nested_list.py\", line 3, in \n sqlparse.parse('[' * 10000 + ']' * 10000)\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/__init__.py\", line 30, in parse\n return tuple(parsestream(sql, encoding))\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/engine/filter_stack.py\", line 36, in run\n stmt = grouping.group(stmt)\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/engine/grouping.py\", line 428, in group\n func(stmt)\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/engine/grouping.py\", line 53, in group_brackets\n _group_matching(tlist, sql.SquareBrackets)\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/engine/grouping.py\", line 48, in _group_matching\n tlist.group_tokens(cls, open_idx, close_idx)\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 328, in group_tokens\n grp = grp_cls(subtokens)\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 161, in __init__\n super().__init__(None, str(self))\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 165, in __str__\n return ''.join(token.value for token in self.flatten())\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 165, in \n return ''.join(token.value for token in self.flatten())\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 214, in flatten\n yield from token.flatten()\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 214, in flatten\n yield from token.flatten()\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 214, in flatten\n yield from token.flatten()\n [Previous line repeated 983 more times]\nRecursionError: maximum recursion depth exceeded\n```\n\n### Fix suggestion\nThe [flatten()](https://github.com/andialbrecht/sqlparse/blob/master/sqlparse/sql.py#L207) function of TokenList class should limit the recursion to a maximal depth:\n```py\nfrom sqlparse.exceptions import SQLParseError\n\nMAX_DEPTH = 100\n\n def flatten(self, depth=1):\n \"\"\"Generator yielding ungrouped tokens.\n\n This method is recursively called for all child tokens.\n \"\"\"\n if depth >= MAX_DEPTH:\n raise SQLParseError('Maximal depth reached')\n for token in self.tokens:\n if token.is_group:\n yield from token.flatten(depth + 1)\n else:\n yield token\n```\n\n### Impact\nDenial of Service (the impact depends on the use).\nAnyone parsing a user input with sqlparse.parse() is affected.\n", diff --git a/audits/buku-requirements.audit.json b/audits/buku-requirements.audit.json index 338570da..732e8093 100644 --- a/audits/buku-requirements.audit.json +++ b/audits/buku-requirements.audit.json @@ -23,7 +23,8 @@ "CGA-4j52-qrxr-72wj", "CGA-mmv2-q2vv-5j43", "CGA-v7pm-fgrf-j9wg", - "CGA-x38f-2x56-r747" + "CGA-x38f-2x56-r747", + "CVE-2024-34069" ], "summary": "Werkzeug debugger vulnerable to remote execution when interacting with attacker controlled domain", "details": "The debugger in affected versions of Werkzeug can allow an attacker to execute code on a developer's machine under some circumstances. This requires the attacker to get the developer to interact with a domain and subdomain they control, and enter the debugger PIN, but if they are successful it allows access to the debugger even if it is only running on localhost. This also requires the attacker to guess a URL in the developer's application that will trigger the debugger.", diff --git a/audits/bzt-requirements.audit.json b/audits/bzt-requirements.audit.json index f78a4697..1e3f09c4 100644 --- a/audits/bzt-requirements.audit.json +++ b/audits/bzt-requirements.audit.json @@ -41,7 +41,8 @@ "CGA-vc35-fw59-66f9", "CGA-vgvj-86h2-mvw3", "CGA-vwcx-7fqm-jggq", - "CGA-w3h9-h7jv-6q22" + "CGA-w3h9-h7jv-6q22", + "CVE-2024-37891" ], "summary": "urllib3's Proxy-Authorization request header isn't stripped during cross-origin redirects", "details": "When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected.\n\nHowever, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects.\n\nBecause this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident.\n\nUsers should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still 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* Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support.\n* Not disabling HTTP redirects.\n* Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin.\n\n## Remediation\n\n* Using the `Proxy-Authorization` header with urllib3's `ProxyManager`.\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Proxy-Authorization` header.", @@ -243,7 +244,8 @@ "CGA-mvfr-2q7x-4qfj", "CGA-mvgq-jv97-4g66", "CGA-qmpr-qhrc-f7m6", - "CGA-vrf3-m7hm-2jfq" + "CGA-vrf3-m7hm-2jfq", + "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", diff --git a/audits/charmcraft-requirements.audit.json b/audits/charmcraft-requirements.audit.json index 8cb32fbe..49123723 100644 --- a/audits/charmcraft-requirements.audit.json +++ b/audits/charmcraft-requirements.audit.json @@ -330,7 +330,8 @@ "CGA-v263-vf6g-w8hh", "CGA-v542-whj6-7mj4", "CGA-whqq-jwxh-vf92", - "CGA-x395-8f45-7j43" + "CGA-x395-8f45-7j43", + "CVE-2024-35195" ], "summary": "Requests `Session` object does not verify requests after making first request with verify=False", "details": "When making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same origin will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool.\n\n### Remediation\nAny of these options can be used to remediate the current issue, we highly recommend upgrading as the preferred mitigation.\n\n* Upgrade to `requests>=2.32.0`.\n* For `requests<2.32.0`, avoid setting `verify=False` for the first request to a host while using a Requests Session.\n* For `requests<2.32.0`, call `close()` on `Session` objects to clear existing connections if `verify=False` is used.\n\n### Related Links\n* https://github.com/psf/requests/pull/6655", diff --git a/audits/dxpy-requirements.audit.json b/audits/dxpy-requirements.audit.json index 7b7aed0a..49ff7ba2 100644 --- a/audits/dxpy-requirements.audit.json +++ b/audits/dxpy-requirements.audit.json @@ -41,7 +41,8 @@ "CGA-vc35-fw59-66f9", "CGA-vgvj-86h2-mvw3", "CGA-vwcx-7fqm-jggq", - "CGA-w3h9-h7jv-6q22" + "CGA-w3h9-h7jv-6q22", + "CVE-2024-37891" ], "summary": "urllib3's Proxy-Authorization request header isn't stripped during cross-origin redirects", "details": "When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected.\n\nHowever, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects.\n\nBecause this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident.\n\nUsers should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still 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* Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support.\n* Not disabling HTTP redirects.\n* Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin.\n\n## Remediation\n\n* Using the `Proxy-Authorization` header with urllib3's `ProxyManager`.\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Proxy-Authorization` header.", diff --git a/audits/ecs-deploy-requirements.audit.json b/audits/ecs-deploy-requirements.audit.json index 522e454e..6e01a842 100644 --- a/audits/ecs-deploy-requirements.audit.json +++ b/audits/ecs-deploy-requirements.audit.json @@ -39,7 +39,8 @@ "CGA-v263-vf6g-w8hh", "CGA-v542-whj6-7mj4", "CGA-whqq-jwxh-vf92", - "CGA-x395-8f45-7j43" + "CGA-x395-8f45-7j43", + "CVE-2024-35195" ], "summary": "Requests `Session` object does not verify requests after making first request with verify=False", "details": "When making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same origin will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool.\n\n### Remediation\nAny of these options can be used to remediate the current issue, we highly recommend upgrading as the preferred mitigation.\n\n* Upgrade to `requests>=2.32.0`.\n* For `requests<2.32.0`, avoid setting `verify=False` for the first request to a host while using a Requests Session.\n* For `requests<2.32.0`, call `close()` on `Session` objects to clear existing connections if `verify=False` is used.\n\n### Related Links\n* https://github.com/psf/requests/pull/6655", @@ -277,7 +278,8 @@ "PYSEC-2023-74" ], "related": [ - "CGA-jw5m-ghm3-2mhw" + "CGA-jw5m-ghm3-2mhw", + "CVE-2023-32681" ], "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)", diff --git a/audits/esphome-requirements.audit.json b/audits/esphome-requirements.audit.json index 1d495423..0f0bce6c 100644 --- a/audits/esphome-requirements.audit.json +++ b/audits/esphome-requirements.audit.json @@ -542,7 +542,8 @@ "CVE-2024-52804" ], "related": [ - "CGA-qpm7-q69q-w66w" + "CGA-qpm7-q69q-w66w", + "CVE-2024-52804" ], "summary": "Tornado has an HTTP cookie parsing DoS vulnerability", "details": "The algorithm used for parsing HTTP cookies in Tornado versions prior to 6.4.2 sometimes has quadratic complexity, leading to excessive CPU consumption when parsing maliciously-crafted cookie headers. This parsing occurs in the event loop thread and may block the processing of other requests.\n\nSee also CVE-2024-7592 for a similar vulnerability in cpython.", diff --git a/audits/flintrock-requirements.audit.json b/audits/flintrock-requirements.audit.json index b725aa88..375886a1 100644 --- a/audits/flintrock-requirements.audit.json +++ b/audits/flintrock-requirements.audit.json @@ -307,7 +307,8 @@ "CGA-xm7f-47qw-j5hm", "CGA-xmhx-5hq2-jjp7", "CGA-xp4m-3h5r-qh7v", - "CGA-xv2r-75ch-26f4" + "CGA-xv2r-75ch-26f4", + "CVE-2023-48795" ], "summary": "Prefix Truncation Attack against ChaCha20-Poly1305 and Encrypt-then-MAC aka Terrapin", "details": "### Summary\n\nTerrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.\n\n### Mitigations\n\nTo mitigate this protocol vulnerability, OpenSSH suggested a so-called \"strict kex\" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes.\n\n**Warning: To take effect, both the client and server must support this countermeasure.** \n\nAs a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.\n\n### Details\n\nThe SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (*-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSH_MSG_EXT_INFO sent after the first message after SSH_MSG_NEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario.\n\nThe attack works by an attacker injecting an arbitrary number of SSH_MSG_IGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSH_MSG_IGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange.\n\nIn the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers.\n\nFor more details see [https://terrapin-attack.com](https://terrapin-attack.com). \n\n### Impact\n\nThis attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (*-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.", @@ -993,7 +994,8 @@ "CGA-vc35-fw59-66f9", "CGA-vgvj-86h2-mvw3", "CGA-vwcx-7fqm-jggq", - "CGA-w3h9-h7jv-6q22" + "CGA-w3h9-h7jv-6q22", + "CVE-2024-37891" ], "summary": "urllib3's Proxy-Authorization request header isn't stripped during cross-origin redirects", "details": "When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected.\n\nHowever, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects.\n\nBecause this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident.\n\nUsers should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still 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* Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support.\n* Not disabling HTTP redirects.\n* Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin.\n\n## Remediation\n\n* Using the `Proxy-Authorization` header with urllib3's `ProxyManager`.\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Proxy-Authorization` header.", diff --git a/audits/ford-requirements.audit.json b/audits/ford-requirements.audit.json index 925a9a1c..db101498 100644 --- a/audits/ford-requirements.audit.json +++ b/audits/ford-requirements.audit.json @@ -19,7 +19,8 @@ ], "related": [ "CGA-5g34-q98x-rv72", - "CGA-wprj-p696-fg4q" + "CGA-wprj-p696-fg4q", + "CVE-2024-34062" ], "summary": "tqdm CLI arguments injection attack", "details": "### Impact\nAny optional non-boolean CLI arguments (e.g. `--delim`, `--buf-size`, `--manpath`) are passed through python's `eval`, allowing arbitrary code execution. Example:\n\n```sh\npython -m tqdm --manpath=\"\\\" + str(exec(\\\"import os\\nos.system('echo hi && killall python3')\\\")) + \\\"\"\n```\n\n### Patches\nhttps://github.com/tqdm/tqdm/commit/4e613f84ed2ae029559f539464df83fa91feb316 released in `tqdm>=4.66.3`\n\n### Workarounds\nNone\n\n### References\n- https://github.com/tqdm/tqdm/releases/tag/v4.66.3", diff --git a/audits/gdbgui-requirements.audit.json b/audits/gdbgui-requirements.audit.json index 6be7c76c..8c1e2101 100644 --- a/audits/gdbgui-requirements.audit.json +++ b/audits/gdbgui-requirements.audit.json @@ -542,7 +542,8 @@ "CGA-ph4r-hmw2-vp9r", "CGA-rwrm-vm7r-mrmj", "CGA-w4rq-c3cf-82f3", - "CGA-x9j2-vg55-h4p4" + "CGA-x9j2-vg55-h4p4", + "CVE-2024-34064" ], "summary": "Jinja vulnerable to HTML attribute injection when passing user input as keys to xmlattr filter", "details": "The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for the previous GHSA-h5c8-rqwp-cp95 CVE-2024-22195 only addressed spaces but not other characters.\n\nAccepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe.", @@ -888,7 +889,8 @@ "CGA-4j52-qrxr-72wj", "CGA-mmv2-q2vv-5j43", "CGA-v7pm-fgrf-j9wg", - "CGA-x38f-2x56-r747" + "CGA-x38f-2x56-r747", + "CVE-2024-34069" ], "summary": "Werkzeug debugger vulnerable to remote execution when interacting with attacker controlled domain", "details": "The debugger in affected versions of Werkzeug can allow an attacker to execute code on a developer's machine under some circumstances. This requires the attacker to get the developer to interact with a domain and subdomain they control, and enter the debugger PIN, but if they are successful it allows access to the debugger even if it is only running on localhost. This also requires the attacker to guess a URL in the developer's application that will trigger the debugger.", @@ -1249,7 +1251,8 @@ "CGA-359g-9qp6-mwmm", "CGA-362w-xpjf-5557", "CGA-3xrx-g66v-9vhw", - "CGA-v94x-q6m7-qgqv" + "CGA-v94x-q6m7-qgqv", + "CVE-2023-46136" ], "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/mycli-requirements.audit.json b/audits/mycli-requirements.audit.json index 167e137d..1acf3d8c 100644 --- a/audits/mycli-requirements.audit.json +++ b/audits/mycli-requirements.audit.json @@ -19,7 +19,8 @@ ], "related": [ "CGA-p7rq-qffc-ch9v", - "CGA-v3hx-x533-rpgf" + "CGA-v3hx-x533-rpgf", + "CVE-2024-4340" ], "summary": "sqlparse parsing heavily nested list leads to Denial of Service", "details": "### Summary\nPassing a heavily nested list to sqlparse.parse() leads to a Denial of Service due to RecursionError.\n\n### Details + PoC\nRunning the following code will raise Maximum recursion limit exceeded exception:\n```py\nimport sqlparse\nsqlparse.parse('[' * 10000 + ']' * 10000)\n```\nWe expect a traceback of RecursionError:\n```py\nTraceback (most recent call last):\n File \"trigger_sqlparse_nested_list.py\", line 3, in \n sqlparse.parse('[' * 10000 + ']' * 10000)\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/__init__.py\", line 30, in parse\n return tuple(parsestream(sql, encoding))\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/engine/filter_stack.py\", line 36, in run\n stmt = grouping.group(stmt)\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/engine/grouping.py\", line 428, in group\n func(stmt)\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/engine/grouping.py\", line 53, in group_brackets\n _group_matching(tlist, sql.SquareBrackets)\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/engine/grouping.py\", line 48, in _group_matching\n tlist.group_tokens(cls, open_idx, close_idx)\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 328, in group_tokens\n grp = grp_cls(subtokens)\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 161, in __init__\n super().__init__(None, str(self))\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 165, in __str__\n return ''.join(token.value for token in self.flatten())\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 165, in \n return ''.join(token.value for token in self.flatten())\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 214, in flatten\n yield from token.flatten()\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 214, in flatten\n yield from token.flatten()\n File \"/home/uriya/.local/lib/python3.10/site-packages/sqlparse/sql.py\", line 214, in flatten\n yield from token.flatten()\n [Previous line repeated 983 more times]\nRecursionError: maximum recursion depth exceeded\n```\n\n### Fix suggestion\nThe [flatten()](https://github.com/andialbrecht/sqlparse/blob/master/sqlparse/sql.py#L207) function of TokenList class should limit the recursion to a maximal depth:\n```py\nfrom sqlparse.exceptions import SQLParseError\n\nMAX_DEPTH = 100\n\n def flatten(self, depth=1):\n \"\"\"Generator yielding ungrouped tokens.\n\n This method is recursively called for all child tokens.\n \"\"\"\n if depth >= MAX_DEPTH:\n raise SQLParseError('Maximal depth reached')\n for token in self.tokens:\n if token.is_group:\n yield from token.flatten(depth + 1)\n else:\n yield token\n```\n\n### Impact\nDenial of Service (the impact depends on the use).\nAnyone parsing a user input with sqlparse.parse() is affected.\n", diff --git a/audits/offlineimap-requirements.audit.json b/audits/offlineimap-requirements.audit.json index 633ad145..1710c160 100644 --- a/audits/offlineimap-requirements.audit.json +++ b/audits/offlineimap-requirements.audit.json @@ -41,7 +41,8 @@ "CGA-vc35-fw59-66f9", "CGA-vgvj-86h2-mvw3", "CGA-vwcx-7fqm-jggq", - "CGA-w3h9-h7jv-6q22" + "CGA-w3h9-h7jv-6q22", + "CVE-2024-37891" ], "summary": "urllib3's Proxy-Authorization request header isn't stripped during cross-origin redirects", "details": "When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected.\n\nHowever, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects.\n\nBecause this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident.\n\nUsers should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still 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* Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support.\n* Not disabling HTTP redirects.\n* Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin.\n\n## Remediation\n\n* Using the `Proxy-Authorization` header with urllib3's `ProxyManager`.\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Proxy-Authorization` header.", @@ -243,7 +244,8 @@ "CGA-mvfr-2q7x-4qfj", "CGA-mvgq-jv97-4g66", "CGA-qmpr-qhrc-f7m6", - "CGA-vrf3-m7hm-2jfq" + "CGA-vrf3-m7hm-2jfq", + "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", @@ -469,6 +471,9 @@ "CVE-2021-33503", "PYSEC-2021-108" ], + "related": [ + "CVE-2021-33503" + ], "summary": "Catastrophic backtracking in URL authority parser when passed URL containing many @ characters", "details": "### Impact\n\nWhen provided with a URL containing many `@` characters in the authority component the authority regular expression exhibits catastrophic backtracking causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.\n\n\n### Patches\n\nThe issue has been fixed in urllib3 v1.26.5.\n\n### References\n\n- [CVE-2021-33503](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33503)\n- [JVNVU#92413403 (English)](https://jvn.jp/en/vu/JVNVU92413403/)\n- [JVNVU#92413403 (Japanese)](https://jvn.jp/vu/JVNVU92413403/)\n- [urllib3 v1.26.5](https://github.com/urllib3/urllib3/releases/tag/1.26.5)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Ask in our [community Discord](https://discord.gg/urllib3)\n* Email [sethmichaellarson@gmail.com](mailto:sethmichaellarson@gmail.com)\n", "affected": [ @@ -589,7 +594,8 @@ "CGA-h89x-4j9m-pw85", "CGA-hwhv-g3qw-gfgp", "CGA-jj8v-vhq7-m6wh", - "CGA-mqx7-jxgh-vrfr" + "CGA-mqx7-jxgh-vrfr", + "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.", diff --git a/audits/raven-requirements.audit.json b/audits/raven-requirements.audit.json index 51f08c0f..6a3decfb 100644 --- a/audits/raven-requirements.audit.json +++ b/audits/raven-requirements.audit.json @@ -39,7 +39,8 @@ "CGA-v263-vf6g-w8hh", "CGA-v542-whj6-7mj4", "CGA-whqq-jwxh-vf92", - "CGA-x395-8f45-7j43" + "CGA-x395-8f45-7j43", + "CVE-2024-35195" ], "summary": "Requests `Session` object does not verify requests after making first request with verify=False", "details": "When making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same origin will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool.\n\n### Remediation\nAny of these options can be used to remediate the current issue, we highly recommend upgrading as the preferred mitigation.\n\n* Upgrade to `requests>=2.32.0`.\n* For `requests<2.32.0`, avoid setting `verify=False` for the first request to a host while using a Requests Session.\n* For `requests<2.32.0`, call `close()` on `Session` objects to clear existing connections if `verify=False` is used.\n\n### Related Links\n* https://github.com/psf/requests/pull/6655", @@ -301,7 +302,8 @@ ], "related": [ "CGA-5g34-q98x-rv72", - "CGA-wprj-p696-fg4q" + "CGA-wprj-p696-fg4q", + "CVE-2024-34062" ], "summary": "tqdm CLI arguments injection attack", "details": "### Impact\nAny optional non-boolean CLI arguments (e.g. `--delim`, `--buf-size`, `--manpath`) are passed through python's `eval`, allowing arbitrary code execution. Example:\n\n```sh\npython -m tqdm --manpath=\"\\\" + str(exec(\\\"import os\\nos.system('echo hi && killall python3')\\\")) + \\\"\"\n```\n\n### Patches\nhttps://github.com/tqdm/tqdm/commit/4e613f84ed2ae029559f539464df83fa91feb316 released in `tqdm>=4.66.3`\n\n### Workarounds\nNone\n\n### References\n- https://github.com/tqdm/tqdm/releases/tag/v4.66.3", @@ -556,7 +558,8 @@ "CGA-vc35-fw59-66f9", "CGA-vgvj-86h2-mvw3", "CGA-vwcx-7fqm-jggq", - "CGA-w3h9-h7jv-6q22" + "CGA-w3h9-h7jv-6q22", + "CVE-2024-37891" ], "summary": "urllib3's Proxy-Authorization request header isn't stripped during cross-origin redirects", "details": "When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected.\n\nHowever, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects.\n\nBecause this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident.\n\nUsers should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still 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* Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support.\n* Not disabling HTTP redirects.\n* Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin.\n\n## Remediation\n\n* Using the `Proxy-Authorization` header with urllib3's `ProxyManager`.\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Proxy-Authorization` header.", diff --git a/audits/scoutsuite-requirements.audit.json b/audits/scoutsuite-requirements.audit.json index 13ccc6f1..eb06c002 100644 --- a/audits/scoutsuite-requirements.audit.json +++ b/audits/scoutsuite-requirements.audit.json @@ -47,6 +47,7 @@ "CGA-4gf6-v2x3-r55p", "CGA-4hfg-7vmx-9jvw", "CGA-4q6g-7c97-xpcc", + "CGA-4wjw-qhr2-p3mg", "CGA-525c-q846-rphh", "CGA-562h-vqjm-ghfg", "CGA-56xw-wjg8-j46r", diff --git a/audits/shub-requirements.audit.json b/audits/shub-requirements.audit.json index a2bc0e35..16a7a194 100644 --- a/audits/shub-requirements.audit.json +++ b/audits/shub-requirements.audit.json @@ -19,7 +19,8 @@ ], "related": [ "CGA-5g34-q98x-rv72", - "CGA-wprj-p696-fg4q" + "CGA-wprj-p696-fg4q", + "CVE-2024-34062" ], "summary": "tqdm CLI arguments injection attack", "details": "### Impact\nAny optional non-boolean CLI arguments (e.g. `--delim`, `--buf-size`, `--manpath`) are passed through python's `eval`, allowing arbitrary code execution. Example:\n\n```sh\npython -m tqdm --manpath=\"\\\" + str(exec(\\\"import os\\nos.system('echo hi && killall python3')\\\")) + \\\"\"\n```\n\n### Patches\nhttps://github.com/tqdm/tqdm/commit/4e613f84ed2ae029559f539464df83fa91feb316 released in `tqdm>=4.66.3`\n\n### Workarounds\nNone\n\n### References\n- https://github.com/tqdm/tqdm/releases/tag/v4.66.3", diff --git a/audits/sickchill-requirements.audit.json b/audits/sickchill-requirements.audit.json index e583611e..fc458977 100644 --- a/audits/sickchill-requirements.audit.json +++ b/audits/sickchill-requirements.audit.json @@ -694,7 +694,8 @@ "CVE-2024-52804" ], "related": [ - "CGA-qpm7-q69q-w66w" + "CGA-qpm7-q69q-w66w", + "CVE-2024-52804" ], "summary": "Tornado has an HTTP cookie parsing DoS vulnerability", "details": "The algorithm used for parsing HTTP cookies in Tornado versions prior to 6.4.2 sometimes has quadratic complexity, leading to excessive CPU consumption when parsing maliciously-crafted cookie headers. This parsing occurs in the event loop thread and may block the processing of other requests.\n\nSee also CVE-2024-7592 for a similar vulnerability in cpython.", diff --git a/audits/tern-requirements.audit.json b/audits/tern-requirements.audit.json index a933d203..fd75de43 100644 --- a/audits/tern-requirements.audit.json +++ b/audits/tern-requirements.audit.json @@ -18,6 +18,9 @@ "CVE-2024-22190", "PYSEC-2024-4" ], + "related": [ + "CVE-2024-22190" + ], "summary": "Untrusted search path under some conditions on Windows allows arbitrary code execution", "details": "### Summary\n\nThis issue exists because of an incomplete fix for CVE-2023-40590. On Windows, GitPython uses an untrusted search path if it uses a shell to run `git`, as well as when it runs `bash.exe` to interpret hooks. If either of those features are used on Windows, a malicious `git.exe` or `bash.exe` may be run from an untrusted repository.\n\n### Details\n\nAlthough GitPython often avoids executing programs found in an untrusted search path since 3.1.33, two situations remain where this still occurs. Either can allow arbitrary code execution under some circumstances.\n\n#### When a shell is used\n\nGitPython can be told to run `git` commands through a shell rather than as direct subprocesses, by passing `shell=True` to any method that accepts it, or by both setting `Git.USE_SHELL = True` and not passing `shell=False`. Then the Windows `cmd.exe` shell process performs the path search, and GitPython does not prevent that shell from finding and running `git` in the current directory.\n\nWhen GitPython runs `git` directly rather than through a shell, the GitPython process performs the path search, and currently omits the current directory by setting `NoDefaultCurrentDirectoryInExePath` in its own environment during the `Popen` call. Although the `cmd.exe` shell will honor this environment variable when present, GitPython does not currently pass it into the shell subprocess's environment.\n\nFurthermore, because GitPython sets the subprocess CWD to the root of a repository's working tree, using a shell will run a malicious `git.exe` in an untrusted repository even if GitPython itself is run from a trusted location.\n\nThis also applies if `Git.execute` is called directly with `shell=True` (or after `Git.USE_SHELL = True`) to run any command.\n\n#### When hook scripts are run\n\nOn Windows, GitPython uses `bash.exe` to run hooks that appear to be scripts. However, unlike when running `git`, no steps are taken to avoid finding and running `bash.exe` in the current directory.\n\nThis allows the author of an untrusted fork or branch to cause a malicious `bash.exe` to be run in some otherwise safe workflows. An example of such a scenario is if the user installs a trusted hook while on a trusted branch, then switches to an untrusted feature branch (possibly from a fork) to review proposed changes. If the untrusted feature branch contains a malicious `bash.exe` and the user's current working directory is the working tree, and the user performs an action that runs the hook, then although the hook itself is uncorrupted, it runs with the malicious `bash.exe`.\n\nNote that, while `bash.exe` is a shell, this is a separate scenario from when `git` is run using the unrelated Windows `cmd.exe` shell.\n\n### PoC\n\nOn Windows, create a `git.exe` file in a repository. Then create a `Repo` object, and call any method through it (directly or indirectly) that supports the `shell` keyword argument with `shell=True`:\n\n```powershell\nmkdir testrepo\ngit init testrepo\ncp ... testrepo git.exe # Replace \"...\" with any executable of choice.\npython -c \"import git; print(git.Repo('testrepo').git.version(shell=True))\"\n```\n\nThe `git.exe` executable in the repository directory will be run.\n\nOr use no `Repo` object, but do it from the location with the `git.exe`:\n\n```powershell\ncd testrepo\npython -c \"import git; print(git.Git().version(shell=True))\"\n```\n\nThe `git.exe` executable in the current directory will be run.\n\nFor the scenario with hooks, install a hook in a repository, create a `bash.exe` file in the current directory, and perform an operation that causes GitPython to attempt to run the hook:\n\n```powershell\nmkdir testrepo\ncd testrepo\ngit init\nmv .git/hooks/pre-commit.sample .git/hooks/pre-commit\ncp ... bash.exe # Replace \"...\" with any executable of choice.\necho \"Some text\" >file.txt\ngit add file.txt\npython -c \"import git; git.Repo().index.commit('Some message')\"\n```\n\nThe `bash.exe` executable in the current directory will be run.\n\n### Impact\n\nThe greatest impact is probably in applications that set `Git.USE_SHELL = True` for historical reasons. (Undesired console windows had, in the past, been created in some kinds of applications, when it was not used.) Such an application may be vulnerable to arbitrary code execution from a malicious repository, even with no other exacerbating conditions. This is to say that, if a shell is used to run `git`, the full effect of CVE-2023-40590 is still present. Furthermore, as noted above, running the application itself from a trusted directory is not a sufficient mitigation.\n\nAn application that does not direct GitPython to use a shell to run `git` subprocesses thus avoids most of the risk. However, there is no such straightforward way to prevent GitPython from running `bash.exe` to interpret hooks. So while the conditions needed for that to be exploited are more involved, it may be harder to mitigate decisively prior to patching.\n\n### Possible solutions\n\nA straightforward approach would be to address each bug directly:\n\n- When a shell is used, pass `NoDefaultCurrentDirectoryInExePath` into the subprocess environment, because in that scenario the subprocess is the `cmd.exe` shell that itself performs the path search.\n- Set `NoDefaultCurrentDirectoryInExePath` in the GitPython process environment during the `Popen` call made to run hooks with a `bash.exe` subprocess.\n\nThese need only be done on Windows.", "affected": [ @@ -195,6 +198,9 @@ "CVE-2023-41040", "PYSEC-2023-165" ], + "related": [ + "CVE-2023-41040" + ], "summary": "GitPython 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.", "affected": [ @@ -385,6 +391,9 @@ "CVE-2023-40590", "PYSEC-2023-161" ], + "related": [ + "CVE-2023-40590" + ], "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.", "affected": [ @@ -1339,7 +1348,8 @@ "CGA-v263-vf6g-w8hh", "CGA-v542-whj6-7mj4", "CGA-whqq-jwxh-vf92", - "CGA-x395-8f45-7j43" + "CGA-x395-8f45-7j43", + "CVE-2024-35195" ], "summary": "Requests `Session` object does not verify requests after making first request with verify=False", "details": "When making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same origin will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool.\n\n### Remediation\nAny of these options can be used to remediate the current issue, we highly recommend upgrading as the preferred mitigation.\n\n* Upgrade to `requests>=2.32.0`.\n* For `requests<2.32.0`, avoid setting `verify=False` for the first request to a host while using a Requests Session.\n* For `requests<2.32.0`, call `close()` on `Session` objects to clear existing connections if `verify=False` is used.\n\n### Related Links\n* https://github.com/psf/requests/pull/6655", @@ -2299,7 +2309,8 @@ "CGA-vc35-fw59-66f9", "CGA-vgvj-86h2-mvw3", "CGA-vwcx-7fqm-jggq", - "CGA-w3h9-h7jv-6q22" + "CGA-w3h9-h7jv-6q22", + "CVE-2024-37891" ], "summary": "urllib3's Proxy-Authorization request header isn't stripped during cross-origin redirects", "details": "When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected.\n\nHowever, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects.\n\nBecause this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident.\n\nUsers should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still 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* Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support.\n* Not disabling HTTP redirects.\n* Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin.\n\n## Remediation\n\n* Using the `Proxy-Authorization` header with urllib3's `ProxyManager`.\n* Disabling HTTP redirects using `redirects=False` when sending requests.\n* Not using the `Proxy-Authorization` header.", @@ -2501,7 +2512,8 @@ "CGA-mvfr-2q7x-4qfj", "CGA-mvgq-jv97-4g66", "CGA-qmpr-qhrc-f7m6", - "CGA-vrf3-m7hm-2jfq" + "CGA-vrf3-m7hm-2jfq", + "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", @@ -2734,7 +2746,8 @@ "CGA-h89x-4j9m-pw85", "CGA-hwhv-g3qw-gfgp", "CGA-jj8v-vhq7-m6wh", - "CGA-mqx7-jxgh-vrfr" + "CGA-mqx7-jxgh-vrfr", + "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.", diff --git a/audits/theharvester-requirements.audit.json b/audits/theharvester-requirements.audit.json index 9bcdaa87..8d8230a8 100644 --- a/audits/theharvester-requirements.audit.json +++ b/audits/theharvester-requirements.audit.json @@ -19,7 +19,8 @@ ], "related": [ "CGA-2j5f-hmjp-gqjm", - "CGA-w2cp-3rgq-pfhv" + "CGA-w2cp-3rgq-pfhv", + "CVE-2024-30251" ], "summary": "aiohttp vulnerable to Denial of Service when trying to parse malformed POST requests", "details": "### Summary\nAn attacker can send a specially crafted POST (multipart/form-data) request. When the aiohttp server processes it, the server will enter an infinite loop and be unable to process any further requests.\n\n### Impact\nAn attacker can stop the application from serving requests after sending a single request.\n\n-------\n\nFor anyone needing to patch older versions of aiohttp, the minimum diff needed to resolve the issue is (located in `_read_chunk_from_length()`):\n\n```diff\ndiff --git a/aiohttp/multipart.py b/aiohttp/multipart.py\nindex 227be605c..71fc2654a 100644\n--- a/aiohttp/multipart.py\n+++ b/aiohttp/multipart.py\n@@ -338,6 +338,8 @@ class BodyPartReader:\n assert self._length is not None, \"Content-Length required for chunked read\"\n chunk_size = min(size, self._length - self._read_bytes)\n chunk = await self._content.read(chunk_size)\n+ if self._content.at_eof():\n+ self._at_eof = True\n return chunk\n \n async def _read_chunk_from_stream(self, size: int) -> bytes:\n```\n\nThis does however introduce some very minor issues with handling form data. So, if possible, it would be recommended to also backport the changes in:\nhttps://github.com/aio-libs/aiohttp/commit/cebe526b9c34dc3a3da9140409db63014bc4cf19\nhttps://github.com/aio-libs/aiohttp/commit/7eecdff163ccf029fbb1ddc9de4169d4aaeb6597\nhttps://github.com/aio-libs/aiohttp/commit/f21c6f2ca512a026ce7f0f6c6311f62d6a638866", @@ -337,7 +338,8 @@ "CGA-692f-82fw-6r2x", "CGA-9vpw-h525-h8jq", "CGA-hvh4-9vf6-26pc", - "CGA-jrf3-556m-q585" + "CGA-jrf3-556m-q585", + "CVE-2024-27306" ], "summary": "aiohttp Cross-site Scripting vulnerability on index pages for static file handling", "details": "### Summary\n\nA XSS vulnerability exists on index pages for static file handling.\n\n### Details\n\nWhen using `web.static(..., show_index=True)`, the resulting index pages do not escape file names.\n\nIf users can upload files with arbitrary filenames to the static directory, the server is vulnerable to XSS attacks.\n\n### Workaround\n\nWe have always recommended using a reverse proxy server (e.g. nginx) for serving static files. Users following the recommendation are unaffected.\n\nOther users can disable `show_index` if unable to upgrade.\n\n-----\n\nPatch: https://github.com/aio-libs/aiohttp/pull/8319/files", @@ -1390,7 +1392,8 @@ "CGA-v263-vf6g-w8hh", "CGA-v542-whj6-7mj4", "CGA-whqq-jwxh-vf92", - "CGA-x395-8f45-7j43" + "CGA-x395-8f45-7j43", + "CVE-2024-35195" ], "summary": "Requests `Session` object does not verify requests after making first request with verify=False", "details": "When making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same origin will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool.\n\n### Remediation\nAny of these options can be used to remediate the current issue, we highly recommend upgrading as the preferred mitigation.\n\n* Upgrade to `requests>=2.32.0`.\n* For `requests<2.32.0`, avoid setting `verify=False` for the first request to a host while using a Requests Session.\n* For `requests<2.32.0`, call `close()` on `Session` objects to clear existing connections if `verify=False` is used.\n\n### Related Links\n* https://github.com/psf/requests/pull/6655", diff --git a/audits/virtualfish-requirements.audit.json b/audits/virtualfish-requirements.audit.json deleted file mode 100644 index b86ebef1..00000000 --- a/audits/virtualfish-requirements.audit.json +++ /dev/null @@ -1,326 +0,0 @@ -[ - { - "package": { - "name": "virtualenv", - "version": "20.26.1", - "ecosystem": "PyPI" - }, - "dependency_groups": [ - "virtualfish-requirements" - ], - "vulnerabilities": [ - { - "modified": "2025-01-13T17:12:00Z", - "published": "2024-11-24T18:31:39Z", - "schema_version": "1.6.0", - "id": "GHSA-rqc4-2hc7-8c8v", - "aliases": [ - "BIT-virtualenv-2024-53899", - "CVE-2024-53899" - ], - "summary": "virtualenv allows command injection through activation scripts for a virtual environment", - "details": "virtualenv before 20.26.6 allows command injection through the activation scripts for a virtual environment. Magic template strings are not quoted correctly when replacing. NOTE: this is not the same as CVE-2024-9287.", - "affected": [ - { - "package": { - "ecosystem": "PyPI", - "name": "virtualenv", - "purl": "pkg:pypi/virtualenv" - }, - "ranges": [ - { - "type": "ECOSYSTEM", - "events": [ - { - "introduced": "0" - }, - { - "fixed": "20.26.6" - } - ] - } - ], - "versions": [ - "0.8", - "0.8.1", - "0.8.2", - "0.8.3", - "0.8.4", - "0.9", - "0.9.1", - "0.9.2", - "1.0", - "1.1", - "1.10", - "1.10.1", - "1.11", - "1.11.1", - "1.11.2", - "1.11.3", - "1.11.4", - "1.11.5", - "1.11.6", - "1.2", - "1.3", - "1.3.1", - "1.3.2", - "1.3.3", - "1.3.4", - "1.4", - "1.4.1", - "1.4.2", - "1.4.3", - "1.4.4", - "1.4.5", - "1.4.6", - "1.4.7", - "1.4.8", - "1.4.9", - "1.4rc1", - "1.5", - "1.5.1", - "1.5.2", - "1.6", - "1.6.1", - "1.6.2", - "1.6.3", - "1.6.4", - "1.7", - "1.7.1", - "1.7.1.1", - "1.7.1.2", - "1.7.2", - "1.8", - "1.8.1", - "1.8.2", - "1.8.3", - "1.8.4", - "1.9", - "1.9.1", - "12.0", - "12.0.1", - "12.0.2", - "12.0.4", - "12.0.5", - "12.0.6", - "12.0.7", - "12.1.0", - "12.1.1", - "13.0.0", - "13.0.1", - "13.0.2", - "13.0.3", - "13.1.0", - "13.1.1", - "13.1.2", - "14.0.0", - "14.0.1", - "14.0.2", - "14.0.3", - "14.0.4", - "14.0.5", - "14.0.6", - "15.0.0", - "15.0.1", - "15.0.2", - "15.0.3", - "15.1.0", - "15.2.0", - "16.0.0", - "16.1.0", - "16.2.0", - "16.3.0", - "16.3.1.dev0", - "16.4.0", - "16.4.1", - "16.4.3", - "16.4.4.dev0", - "16.5.0", - "16.6.0", - "16.6.1", - "16.6.2", - "16.7.0", - "16.7.1", - "16.7.10", - "16.7.11", - "16.7.12", - "16.7.2", - "16.7.3", - "16.7.4", - "16.7.5", - "16.7.6", - "16.7.7", - "16.7.8", - "16.7.9", - "20.0.0", - "20.0.0b1", - "20.0.0b2", - "20.0.1", - "20.0.10", - "20.0.11", - "20.0.12", - "20.0.13", - "20.0.14", - "20.0.15", - "20.0.16", - "20.0.17", - "20.0.18", - "20.0.19", - "20.0.2", - "20.0.20", - "20.0.21", - "20.0.22", - "20.0.23", - "20.0.24", - "20.0.25", - "20.0.26", - "20.0.27", - "20.0.28", - "20.0.29", - "20.0.3", - "20.0.30", - "20.0.31", - "20.0.32", - "20.0.33", - "20.0.34", - "20.0.35", - "20.0.4", - "20.0.5", - "20.0.6", - "20.0.7", - "20.0.8", - "20.0.9", - "20.1.0", - "20.10.0", - "20.11.0", - "20.11.1", - "20.11.2", - "20.12.0", - "20.12.1", - "20.13.0", - "20.13.1", - "20.13.2", - "20.13.3", - "20.13.4", - "20.14.0", - "20.14.1", - "20.15.0", - "20.15.1", - "20.16.0", - "20.16.1", - "20.16.2", - "20.16.3", - "20.16.4", - "20.16.5", - "20.16.6", - "20.16.7", - "20.17.0", - "20.17.1", - "20.18.0", - "20.19.0", - "20.2.0", - "20.2.1", - "20.2.2", - "20.20.0", - "20.21.0", - "20.21.1", - "20.22.0", - "20.23.0", - "20.23.1", - "20.24.0", - "20.24.1", - "20.24.2", - "20.24.3", - "20.24.4", - "20.24.5", - "20.24.6", - "20.24.7", - "20.25.0", - "20.25.1", - "20.25.2", - "20.25.3", - "20.26.0", - "20.26.1", - "20.26.2", - "20.26.3", - "20.26.4", - "20.26.5", - "20.3.0", - "20.3.1", - "20.4.0", - "20.4.1", - "20.4.2", - "20.4.3", - "20.4.4", - "20.4.5", - "20.4.6", - "20.4.7", - "20.5.0", - "20.6.0", - "20.7.0", - "20.7.1", - "20.7.2", - "20.8.0", - "20.8.1", - "20.9.0" - ], - "database_specific": { - "source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2024/11/GHSA-rqc4-2hc7-8c8v/GHSA-rqc4-2hc7-8c8v.json" - } - } - ], - "severity": [ - { - "type": "CVSS_V3", - "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H" - } - ], - "references": [ - { - "type": "ADVISORY", - "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53899" - }, - { - "type": "WEB", - "url": "https://github.com/pypa/virtualenv/issues/2768" - }, - { - "type": "WEB", - "url": "https://github.com/pypa/virtualenv/pull/2771" - }, - { - "type": "PACKAGE", - "url": "https://github.com/pypa/virtualenv" - }, - { - "type": "WEB", - "url": "https://github.com/pypa/virtualenv/releases/tag/20.26.6" - } - ], - "database_specific": { - "cwe_ids": [ - "CWE-77", - "CWE-78" - ], - "github_reviewed": true, - "github_reviewed_at": "2025-01-13T17:01:51Z", - "nvd_published_at": "2024-11-24T16:15:06Z", - "severity": "HIGH" - } - } - ], - "groups": [ - { - "ids": [ - "GHSA-rqc4-2hc7-8c8v" - ], - "aliases": [ - "BIT-virtualenv-2024-53899", - "CVE-2024-53899", - "GHSA-rqc4-2hc7-8c8v" - ], - "max_severity": "8.4" - } - ] - } -] \ No newline at end of file diff --git a/audits/woob-requirements.audit.json b/audits/woob-requirements.audit.json index 50f12ea0..29984913 100644 --- a/audits/woob-requirements.audit.json +++ b/audits/woob-requirements.audit.json @@ -39,7 +39,8 @@ "CGA-v263-vf6g-w8hh", "CGA-v542-whj6-7mj4", "CGA-whqq-jwxh-vf92", - "CGA-x395-8f45-7j43" + "CGA-x395-8f45-7j43", + "CVE-2024-35195" ], "summary": "Requests `Session` object does not verify requests after making first request with verify=False", "details": "When making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same origin will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool.\n\n### Remediation\nAny of these options can be used to remediate the current issue, we highly recommend upgrading as the preferred mitigation.\n\n* Upgrade to `requests>=2.32.0`.\n* For `requests<2.32.0`, avoid setting `verify=False` for the first request to a host while using a Requests Session.\n* For `requests<2.32.0`, call `close()` on `Session` objects to clear existing connections if `verify=False` is used.\n\n### Related Links\n* https://github.com/psf/requests/pull/6655", diff --git a/requirements/awscli@1-requirements.txt b/requirements/awscli@1-requirements.txt index 4cbe1e56..fa1ec218 100644 --- a/requirements/awscli@1-requirements.txt +++ b/requirements/awscli@1-requirements.txt @@ -1,4 +1,4 @@ -botocore==1.35.89 +botocore==1.35.99 colorama==0.4.6 docutils==0.16 jmespath==1.0.1 diff --git a/requirements/cfn-lint-requirements.txt b/requirements/cfn-lint-requirements.txt index 4e1bd1fa..79bd3588 100644 --- a/requirements/cfn-lint-requirements.txt +++ b/requirements/cfn-lint-requirements.txt @@ -1,8 +1,8 @@ annotated-types==0.7.0 attrs==24.3.0 aws-sam-translator==1.94.0 -boto3==1.35.95 -botocore==1.35.95 +boto3==1.35.98 +botocore==1.35.98 jmespath==1.0.1 jsonpatch==1.33 jsonpointer==3.0.0 diff --git a/requirements/gptme-requirements.txt b/requirements/gptme-requirements.txt index de1fedbb..b52856a9 100644 --- a/requirements/gptme-requirements.txt +++ b/requirements/gptme-requirements.txt @@ -1,10 +1,10 @@ annotated-types==0.7.0 anthropic==0.42.0 -anyio==4.7.0 +anyio==4.8.0 asttokens==3.0.0 bashlex==0.18 -charset-normalizer==3.4.0 -click==8.1.7 +charset-normalizer==3.4.1 +click==8.1.8 decorator==5.1.1 distro==1.9.0 executing==2.1.0 @@ -21,7 +21,7 @@ markdown-it-py==3.0.0 matplotlib-inline==0.1.7 mdurl==0.1.2 multiprocessing-logging==any.whl -openai==1.58.1 +openai==1.59.7 parso==0.8.4 pexpect==4.9.0 pick==2.4.0 @@ -29,9 +29,9 @@ platformdirs==4.3.6 prompt-toolkit==3.0.48 ptyprocess==0.7.0 pure-eval==0.2.3 -pydantic==2.10.4 +pydantic==2.10.5 pydantic-core==2.27.2 -pygments==2.18.0 +pygments==2.19.1 python-dotenv==1.0.1 python-xlib==0.33 regex==2024.11.6 @@ -46,5 +46,5 @@ tomlkit==0.13.2 tqdm==4.67.1 traitlets==5.14.3 typing-extensions==4.12.2 -urllib3==2.2.3 +urllib3==2.3.0 wcwidth==0.2.13 diff --git a/requirements/graph-tool-requirements.txt b/requirements/graph-tool-requirements.txt index 7d3e3333..d3837295 100644 --- a/requirements/graph-tool-requirements.txt +++ b/requirements/graph-tool-requirements.txt @@ -6,6 +6,6 @@ matplotlib==3.10.0 packaging==24.2 pyparsing==3.2.1 python-dateutil==2.9.0.post0 -setuptools==75.7.0 +setuptools==75.8.0 six==1.17.0 zstandard==0.23.0 diff --git a/requirements/prowler-requirements.txt b/requirements/prowler-requirements.txt index cee61b03..0db6e857 100644 --- a/requirements/prowler-requirements.txt +++ b/requirements/prowler-requirements.txt @@ -3,7 +3,7 @@ aiohappyeyeballs==2.4.4 aiohttp==3.11.11 aiosignal==1.3.2 alive-progress==3.2.0 -anyio==4.7.0 +anyio==4.8.0 attrs==24.3.0 awsipranges==0.3.3 azure-common==1.1.28 @@ -12,14 +12,14 @@ azure-identity==1.19.0 azure-keyvault-keys==4.10.0 azure-mgmt-applicationinsights==4.0.0 azure-mgmt-authorization==4.0.0 -azure-mgmt-compute==33.0.0 +azure-mgmt-compute==33.1.0 azure-mgmt-containerregistry==10.3.0 azure-mgmt-containerservice==33.0.0 azure-mgmt-core==1.5.0 azure-mgmt-cosmosdb==9.7.0 azure-mgmt-keyvault==10.3.1 azure-mgmt-monitor==6.0.2 -azure-mgmt-network==28.0.0 +azure-mgmt-network==28.1.0 azure-mgmt-rdbms==10.1.0 azure-mgmt-resource==23.2.0 azure-mgmt-search==9.1.0 @@ -30,10 +30,10 @@ azure-mgmt-subscription==3.1.1 azure-mgmt-web==7.3.1 azure-storage-blob==12.24.0 blinker==1.9.0 -boto3==1.35.71 -botocore==1.35.71 +boto3==1.35.94 +botocore==1.35.94 cachetools==5.5.0 -charset-normalizer==3.4.0 +charset-normalizer==3.4.1 click==8.1.8 click-plugins==1.1.1 colorama==0.4.6 @@ -51,7 +51,7 @@ filelock==3.16.1 flask==3.0.3 frozenlist==1.5.0 google-api-core==2.24.0 -google-api-python-client==2.154.0 +google-api-python-client==2.158.0 google-auth==2.37.0 google-auth-httplib2==0.2.0 googleapis-common-protos==1.66.0 @@ -61,7 +61,7 @@ h2==4.1.0 hpack==4.0.0 httpcore==1.0.7 httplib2==0.22.0 -httpx==0.27.2 +httpx==0.28.1 hyperframe==6.0.1 idna==3.10 importlib-metadata==8.5.0 @@ -73,17 +73,17 @@ jsonschema==4.23.0 jsonschema-specifications==2024.10.1 kubernetes==31.0.0 markupsafe==3.0.2 -microsoft-kiota-abstractions==1.6.2 -microsoft-kiota-authentication-azure==1.6.2 -microsoft-kiota-http==1.6.2 -microsoft-kiota-serialization-form==1.6.2 -microsoft-kiota-serialization-json==1.6.2 -microsoft-kiota-serialization-multipart==1.6.2 -microsoft-kiota-serialization-text==1.6.2 +microsoft-kiota-abstractions==1.6.8 +microsoft-kiota-authentication-azure==1.6.8 +microsoft-kiota-http==1.6.8 +microsoft-kiota-serialization-form==1.6.8 +microsoft-kiota-serialization-json==1.6.8 +microsoft-kiota-serialization-multipart==1.6.8 +microsoft-kiota-serialization-text==1.6.8 msal==1.31.1 msal-extensions==1.2.0 -msgraph-core==1.1.8 -msgraph-sdk==1.12.0 +msgraph-core==1.2.0 +msgraph-sdk==1.16.0 msrest==0.7.1 multidict==6.1.0 nest-asyncio==1.6.0 @@ -98,13 +98,13 @@ plotly==5.24.1 portalocker==2.10.1 propcache==0.2.1 proto-plus==1.25.0 -protobuf==5.29.2 +protobuf==5.29.3 py-ocsf-models==0.2.0 pyasn1==0.6.1 pyasn1-modules==0.4.1 pydantic==1.10.18 pyjwt==2.10.1 -pyparsing==3.2.0 +pyparsing==3.2.1 python-dateutil==2.9.0.post0 pytz==2024.2 pyyaml==6.0.2 @@ -117,10 +117,10 @@ rpds-py==0.22.3 rsa==4.9 s3transfer==0.10.4 schema==0.7.7 -setuptools==75.6.0 +setuptools==75.8.0 shodan==1.31.0 six==1.17.0 -slack-sdk==3.33.4 +slack-sdk==3.34.0 sniffio==1.3.1 std-uritemplate==2.0.1 tabulate==0.9.0 @@ -134,7 +134,7 @@ uritemplate==4.1.1 urllib3==2.3.0 websocket-client==1.8.0 werkzeug==3.0.6 -wrapt==1.17.0 +wrapt==1.17.2 xlsxwriter==3.2.0 yarl==1.18.3 zipp==3.21.0 diff --git a/requirements/robot-framework-requirements.txt b/requirements/robot-framework-requirements.txt index 6a7aa7a7..29c63d65 100644 --- a/requirements/robot-framework-requirements.txt +++ b/requirements/robot-framework-requirements.txt @@ -1,23 +1,24 @@ -attrs==24.2.0 -bcrypt==4.2.0 +attrs==24.3.0 +bcrypt==4.2.1 +click==8.1.8 h11==0.14.0 idna==3.10 outcome==1.3.0.post0 paramiko==3.5.0 pynacl==1.5.0 pysocks==1.7.1 -robotframework-archivelibrary==0.4.2 +robotframework-archivelibrary==0.4.3 robotframework-pythonlibcore==4.4.1 robotframework-selenium2library==3.0.0 -robotframework-seleniumlibrary==6.3.0 +robotframework-seleniumlibrary==6.7.0 robotframework-sshlibrary==3.8.0 scp==0.15.0 -selenium==4.25.0 +selenium==4.27.1 sniffio==1.3.1 sortedcontainers==2.4.0 -trio==0.27.0 +trio==0.28.0 trio-websocket==0.11.1 typing-extensions==4.12.2 -urllib3==2.2.3 +urllib3==2.3.0 websocket-client==1.8.0 wsproto==1.2.0 diff --git a/requirements/tmt-requirements.txt b/requirements/tmt-requirements.txt index d4a6ea84..281dada7 100644 --- a/requirements/tmt-requirements.txt +++ b/requirements/tmt-requirements.txt @@ -6,7 +6,7 @@ docutils==0.21.2 filelock==3.16.1 flexcache==0.3 flexparser==0.4 -fmf==1.5.0 +fmf==1.6.0 idna==3.10 jinja2==3.1.5 jsonschema==4.23.0 @@ -15,12 +15,12 @@ markupsafe==3.0.2 packaging==24.2 pint==0.24.4 platformdirs==4.3.6 -pydantic==2.10.4 +pydantic==2.10.5 pydantic-core==2.27.2 -pygments==2.18.0 +pygments==2.19.1 referencing==0.35.1 requests==2.32.3 rpds-py==0.22.3 -ruamel-yaml==0.18.6 +ruamel-yaml==0.18.10 typing-extensions==4.12.2 urllib3==2.3.0 diff --git a/requirements/virtualfish-requirements.txt b/requirements/virtualfish-requirements.txt index 24d41fe7..e5d72633 100644 --- a/requirements/virtualfish-requirements.txt +++ b/requirements/virtualfish-requirements.txt @@ -1,7 +1,7 @@ -distlib==0.3.8 -filelock==3.14.0 -packaging==24.0 +distlib==0.3.9 +filelock==3.16.1 +packaging==24.2 pkgconfig==1.5.5 -platformdirs==4.2.1 -psutil==5.9.8 -virtualenv==20.26.1 +platformdirs==4.3.6 +psutil==6.1.1 +virtualenv==20.28.1