pyup-update-pytest-mock-3.7.0-to-3.11.1
2 years, 10 months ago
Update pytest-mock from 3.7.0 to 3.11.1
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 4 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| requests | 2.27.1 | <2.33.0 |
show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content. |
| requests | 2.27.1 | >=2.3.0,<2.31.0 |
show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information. |
| requests | 2.27.1 | <2.32.4 |
show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session. |
| requests | 2.27.1 | <2.32.2 |
show Affected versions of Requests, 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 host 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. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
pyup-update-pytest-7.1.1-to-7.3.2
2 years, 11 months ago
Update pytest from 7.1.1 to 7.3.2
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 4 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| requests | 2.27.1 | <2.33.0 |
show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content. |
| requests | 2.27.1 | >=2.3.0,<2.31.0 |
show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information. |
| requests | 2.27.1 | <2.32.4 |
show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session. |
| requests | 2.27.1 | <2.32.2 |
show Affected versions of Requests, 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 host 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. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
pyup-update-python-gitlab-3.3.0-to-3.15.0
2 years, 11 months ago
Update python-gitlab from 3.3.0 to 3.15.0
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 4 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| requests | 2.27.1 | <2.33.0 |
show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content. |
| requests | 2.27.1 | >=2.3.0,<2.31.0 |
show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information. |
| requests | 2.27.1 | <2.32.4 |
show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session. |
| requests | 2.27.1 | <2.32.2 |
show Affected versions of Requests, 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 host 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. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
pyup-update-urllib3-1.26.9-to-2.0.3
2 years, 11 months ago
Update urllib3 from 1.26.9 to 2.0.3
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 4 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| requests | 2.27.1 | <2.33.0 |
show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content. |
| requests | 2.27.1 | >=2.3.0,<2.31.0 |
show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information. |
| requests | 2.27.1 | <2.32.4 |
show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session. |
| requests | 2.27.1 | <2.32.2 |
show Affected versions of Requests, 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 host 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. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
pyup-update-markupsafe-2.1.1-to-2.1.3
2 years, 11 months ago
Update markupsafe from 2.1.1 to 2.1.3
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 4 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| requests | 2.27.1 | <2.33.0 |
show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content. |
| requests | 2.27.1 | >=2.3.0,<2.31.0 |
show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information. |
| requests | 2.27.1 | <2.32.4 |
show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session. |
| requests | 2.27.1 | <2.32.2 |
show Affected versions of Requests, 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 host 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. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
pyup-update-coverage-6.3.2-to-7.2.7
2 years, 11 months ago
Update coverage from 6.3.2 to 7.2.7
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 4 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| requests | 2.27.1 | <2.33.0 |
show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content. |
| requests | 2.27.1 | >=2.3.0,<2.31.0 |
show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information. |
| requests | 2.27.1 | <2.32.4 |
show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session. |
| requests | 2.27.1 | <2.32.2 |
show Affected versions of Requests, 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 host 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. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
pyup-update-deprecated-1.2.13-to-1.2.14
2 years, 11 months ago
Update deprecated from 1.2.13 to 1.2.14
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 4 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| requests | 2.27.1 | <2.33.0 |
show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content. |
| requests | 2.27.1 | >=2.3.0,<2.31.0 |
show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information. |
| requests | 2.27.1 | <2.32.4 |
show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session. |
| requests | 2.27.1 | <2.32.2 |
show Affected versions of Requests, 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 host 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. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
pyup-update-pytest-cov-3.0.0-to-4.1.0
2 years, 11 months ago
Update pytest-cov from 3.0.0 to 4.1.0
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 4 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| requests | 2.27.1 | <2.33.0 |
show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content. |
| requests | 2.27.1 | >=2.3.0,<2.31.0 |
show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information. |
| requests | 2.27.1 | <2.32.4 |
show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session. |
| requests | 2.27.1 | <2.32.2 |
show Affected versions of Requests, 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 host 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. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
pyup-update-coverage-6.3.2-to-7.2.6
2 years, 11 months ago
Update coverage from 6.3.2 to 7.2.6
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 4 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| requests | 2.27.1 | <2.33.0 |
show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content. |
| requests | 2.27.1 | >=2.3.0,<2.31.0 |
show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information. |
| requests | 2.27.1 | <2.32.4 |
show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session. |
| requests | 2.27.1 | <2.32.2 |
show Affected versions of Requests, 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 host 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. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
pyup-update-requests-2.27.1-to-2.31.0
2 years, 11 months ago
Update requests from 2.27.1 to 2.31.0
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 3 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
pyup-update-setuptools-61.2.0-to-67.8.0
2 years, 11 months ago
Update setuptools from 61.2.0 to 67.8.0
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 2 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
pyup-update-pyjwt-2.3.0-to-2.7.0
3 years ago
Update pyjwt from 2.3.0 to 2.7.0
py 1.11.0, dparse 0.5.1 and 3 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
pyup-update-pygithub-1.55-to-1.58.2
3 years ago
Update pygithub from 1.55 to 1.58.2
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 3 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
pyup-update-certifi-2021.10.8-to-2023.5.7
3 years ago
Update certifi from 2021.10.8 to 2023.5.7
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 2 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
pyup-update-urllib3-1.26.9-to-2.0.2
3 years ago
Update urllib3 from 1.26.9 to 2.0.2
py 1.11.0, pyjwt 2.3.0, dparse 0.5.1 and 3 other dependencies have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| py | 1.11.0 | <=1.11.0 |
show ** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287 |
| pyjwt | 2.3.0 | >=1.0.0,<2.4.0 |
show PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding. |
| pyjwt | 2.3.0 | <2.12.0 |
show Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token. |
| dparse | 0.5.1 | <0.5.2 |
show Dparse 0.5.2 includes a fix for CVE-2022-39280: Versions before 0.5.2 contain a regular expression that is vulnerable to a Regular Expression Denial of Service. All the users parsing index server URLs with dparse are impacted by this vulnerability. Users unable to upgrade should avoid passing index server URLs in the source file to be parsed. |
| safety | 1.10.3 | <2.2.0 |
show Safety 2.2.0 updates its dependency 'dparse' to include a security fix. |
| certifi | 2021.10.8 | <2022.12.07 |
show Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion. |
| certifi | 2021.10.8 | >=2021.05.30,<2024.07.04 |
show Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store. |
| certifi | 2021.10.8 | >=1.0.1,<2023.07.22 |
show Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7 |
| setuptools | 61.2.0 | <70.0.0 |
show Affected versions of Setuptools allow for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. |
| setuptools | 61.2.0 | <65.5.1 |
show Setuptools 65.5.1 includes a fix for CVE-2022-40897: 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. |
| setuptools | 61.2.0 | <78.1.1 |
show Affected versions of Setuptools are vulnerable to Path Traversal via PackageIndex.download(). The impact is Arbitrary File Overwrite: An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context. |
Python 3 badge
URL
https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/python-3-shield.svg
Markdown
[](https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/)
Restructured Text
.. image:: https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/python-3-shield.svg
:target: https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/
:alt: Python 3
HTML
<a href="https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/"><img src="https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/shield.svg" alt="Python 3" /></a>
Textile
!https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/python-3-shield.svg(Python 3)!:https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/
RDoc
{<img src="https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/python-3-shield.svg" alt="Python 3" />}[https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/]
pyup.io badge
URL
https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/shield.svg
Markdown
[](https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/)
Restructured Text
.. image:: https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/shield.svg
:target: https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/
:alt: Updates
HTML
<a href="https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/"><img src="https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/shield.svg" alt="Updates" /></a>
Textile
!https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/shield.svg(Updates)!:https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/
RDoc
{<img src="https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/shield.svg" alt="Updates" />}[https://pyup.io/repos/github/DanielDevMatos/FirstProjectPython/]