Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Sqlalchemy 2.0.0b1 avoids leaking cleartext passwords to the open for careless uses of str(engine.URL()) in logs and prints.
https://github.com/sqlalchemy/sqlalchemy/pull/8563

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Sqlalchemy 2.0.0b1 avoids leaking cleartext passwords to the open for careless uses of str(engine.URL()) in logs and prints.
https://github.com/sqlalchemy/sqlalchemy/pull/8563

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Sqlalchemy 2.0.0b1 avoids leaking cleartext passwords to the open for careless uses of str(engine.URL()) in logs and prints.
https://github.com/sqlalchemy/sqlalchemy/pull/8563

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Sqlalchemy 2.0.0b1 avoids leaking cleartext passwords to the open for careless uses of str(engine.URL()) in logs and prints.
https://github.com/sqlalchemy/sqlalchemy/pull/8563

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Sqlalchemy 2.0.0b1 avoids leaking cleartext passwords to the open for careless uses of str(engine.URL()) in logs and prints.
https://github.com/sqlalchemy/sqlalchemy/pull/8563

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Sqlalchemy 2.0.0b1 avoids leaking cleartext passwords to the open for careless uses of str(engine.URL()) in logs and prints.
https://github.com/sqlalchemy/sqlalchemy/pull/8563

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Sqlalchemy 2.0.0b1 avoids leaking cleartext passwords to the open for careless uses of str(engine.URL()) in logs and prints.
https://github.com/sqlalchemy/sqlalchemy/pull/8563

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Sqlalchemy 2.0.0b1 avoids leaking cleartext passwords to the open for careless uses of str(engine.URL()) in logs and prints.
https://github.com/sqlalchemy/sqlalchemy/pull/8563

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Sqlalchemy 2.0.0b1 avoids leaking cleartext passwords to the open for careless uses of str(engine.URL()) in logs and prints.
https://github.com/sqlalchemy/sqlalchemy/pull/8563

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Sqlalchemy 2.0.0b1 avoids leaking cleartext passwords to the open for careless uses of str(engine.URL()) in logs and prints.
https://github.com/sqlalchemy/sqlalchemy/pull/8563

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Sqlalchemy 2.0.0b1 avoids leaking cleartext passwords to the open for careless uses of str(engine.URL()) in logs and prints.
https://github.com/sqlalchemy/sqlalchemy/pull/8563

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Sqlalchemy 2.0.0b1 avoids leaking cleartext passwords to the open for careless uses of str(engine.URL()) in logs and prints.
https://github.com/sqlalchemy/sqlalchemy/pull/8563

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209

Click 8.0.0 uses 'mkstemp()' instead of the deprecated & insecure 'mktemp()'.
https://github.com/pallets/click/issues/1752

Flask 2.2.5 and 2.3.2 include a fix for CVE-2023-30861: When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches 'Set-Cookie' headers, it may send one client's 'session' cookie to other clients. The severity depends on the application's use of the session and the proxy's behavior regarding cookies. The risk depends on all these conditions being met:
1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets 'session.permanent = True'
3. The application does not access or modify the session at any point during a request.
4. 'SESSION_REFRESH_EACH_REQUEST' enabled (the default).
5. The application does not set a 'Cache-Control' header to indicate that a page is private or should not be cached.
This happens because vulnerable versions of Flask only set the 'Vary: Cookie' header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.
https://github.com/pallets/flask/security/advisories/GHSA-m2qf-hxjv-5gpq

Mako before 1.2.2 is vulnerable to Regular expression Denial of Service when using the Lexer class to parse. This also affects babelplugin and linguaplugin.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

An error-handling flaw was found in python-ecdsa before version 0.13.3. During signature decoding, malformed DER signatures could raise unexpected exceptions (or no exceptions at all), which could lead to a denial of service. See CVE-2019-14853.

A flaw was found in all python-ecdsa versions before 0.13.3, where it did not correctly verify whether signatures used DER encoding. Without this verification, a malformed signature could be accepted, making the signature malleable. Without proper verification, an attacker could use a malleable signature to create false transactions. See: CVE-2019-14859.

The python-ecdsa library, used for ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This flaw allows the extraction of private keys from ECDSA signatures due to a side-channel in ecdsa.SigningKey.sign_digest(). The vulnerability is pronounced in the signing process, especially in operations involving over 719,882 observations. Key generation and ECDH operations are also affected, but signature verification remains secure.
https://github.com/tlsfuzzer/python-ecdsa/security/advisories/GHSA-wj6h-64fc-37mp

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

In ecdsa 0.14, deterministic signatures verify that the signature won't leak private key through very unlikely selection of `k` value (the nonce). Nonce bit size hiding was added (hardening against Minerva attack). Please note that it DOES NOT make library secure against side channel attacks (timing attacks).
https://github.com/tlsfuzzer/python-ecdsa/commit/b516f06d0e94eca6deeb3bdb82027ad2f2f55ac6

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja2 before 3.1.3 is affected by a Cross-Site Scripting vulnerability. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template. The Jinja 'xmlattr' filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Specific versions of WTForms, a Python web development library, are vulnerable to Cross-site Scripting (XSS) attacks because label names are not escaped. This vulnerability exposes applications to potential malicious scripting through improperly sanitized label fields in forms.

Wtforms 3.0.0a1 escape unsafe characters in label text, patching a potential XSS vulnerability.
https://github.com/wtforms/wtforms/commit/8529b953a0919300794f95e01a7713162908c8a6

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in [email protected] and (if CBC is used) the [email protected] MAC algorithms.

Paramiko 3.4.0 has been released to fix vulnerabilities affecting encrypt-then-MAC digest algorithms in tandem with CBC ciphers, and ChaCha20-poly1305. The fix requires cooperation from both ends of the connection, making it effective when the remote end is OpenSSH >= 9.6 and configured to use the new “strict kex” mode. For further details, refer to the official Paramiko documentation or GitHub repository.
https://github.com/advisories/GHSA-45x7-px36-x8w8

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

Werkzeug 2.2.3 includes a fix for CVE-2023-23934: Browsers may allow "nameless" cookies that look like '=value' instead of 'key=value'. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like '=__Host-test=bad' for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie '=__Host-test=bad' as __Host-test=bad'. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key.
https://github.com/pallets/werkzeug/security/advisories/GHSA-px8h-6qxv-m22q

Werkzeug 0.15.5 includes a fix for an information disclosure vulnerability.
https://github.com/pallets/werkzeug/pull/1592

Werkzeug 3.0.1 and 2.3.8 include a security fix: Slow multipart parsing for large parts potentially enabling DoS attacks.
https://github.com/pallets/werkzeug/commit/b1916c0c083e0be1c9d887ee2f3d696922bfc5c1

Werkzeug 2.2.3 includes a fix for CVE-2023-25577: Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses 'request.data', 'request.form', 'request.files', or 'request.get_data(parse_form_data=False)', it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.
https://github.com/pallets/werkzeug/security/advisories/GHSA-xg9f-g7g7-2323

In Pallets Werkzeug before 0.15.5, SharedDataMiddleware mishandles drive names (such as C:) in Windows pathnames.

Sqlalchemy 2.0.0b1 avoids leaking cleartext passwords to the open for careless uses of str(engine.URL()) in logs and prints.
https://github.com/sqlalchemy/sqlalchemy/pull/8563

Flask-caching is vulnerable to CVE-2021-33026: Flask-Caching extension for Flask relies on Pickle for deserialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code. 
NOTE: Project maintainers indicate that exploitation is extremely unlikely unless the machine is already compromised; in other cases, the attacker would be unable to write their payload to the cache and generate the required collision.
https://github.com/pallets-eco/flask-caching/pull/209