Safety CI > amgsnt/python-ci-integration

pyup-update-gunicorn-20.1.0-to-25.1.0

3 days, 20 hours ago

16c37def

Update gunicorn from 20.1.0 to 25.1.0

Flask 2.2.2 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

pyup-update-gunicorn-20.1.0-to-25.0.3

1 week, 2 days ago

4505f649

Update gunicorn from 20.1.0 to 25.0.3

Flask 2.2.2 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

pyup-update-gunicorn-20.1.0-to-25.0.2

1 week, 3 days ago

427361cd

Update gunicorn from 20.1.0 to 25.0.2

Flask 2.2.2 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

pyup-update-gunicorn-20.1.0-to-25.0.1

2 weeks ago

ad21b620

Update gunicorn from 20.1.0 to 25.0.1

Flask 2.2.2 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

pyup-update-gunicorn-20.1.0-to-25.0.0

2 weeks, 1 day ago

c67bfae6

Update gunicorn from 20.1.0 to 25.0.0

Flask 2.2.2 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

pyup-update-gunicorn-20.1.0-to-24.1.1

3 weeks, 3 days ago

c3f8928d

Update gunicorn from 20.1.0 to 24.1.1

Flask 2.2.2 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

pyup-update-gunicorn-20.1.0-to-24.1.0

3 weeks, 3 days ago

cef7ddd2

Update gunicorn from 20.1.0 to 24.1.0

Flask 2.2.2 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

pyup-update-gunicorn-20.1.0-to-24.0.0

3 weeks, 4 days ago

6799cd3b

Update gunicorn from 20.1.0 to 24.0.0

Flask 2.2.2 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

pyup-update-pytest-7.1.3-to-9.0.2

2 months, 1 week ago

d80774e5

Update pytest from 7.1.3 to 9.0.2

Flask 2.2.2 and gunicorn 20.1.0 have known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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
gunicorn	20.1.0	<22.0.0	show Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.
gunicorn	20.1.0	<22.0.0	show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

gunicorn

20.1.0

<22.0.0

show

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

gunicorn

20.1.0

<22.0.0

show

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

pyup-update-pytest-7.1.3-to-9.0.1

3 months ago

16d0e2af

Update pytest from 7.1.3 to 9.0.1

Flask 2.2.2 and gunicorn 20.1.0 have known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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
gunicorn	20.1.0	<22.0.0	show Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.
gunicorn	20.1.0	<22.0.0	show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

gunicorn

20.1.0

<22.0.0

show

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

gunicorn

20.1.0

<22.0.0

show

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

pyup-update-pytest-7.1.3-to-9.0.0

3 months, 1 week ago

53ae22ff

Update pytest from 7.1.3 to 9.0.0

Flask 2.2.2 and gunicorn 20.1.0 have known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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
gunicorn	20.1.0	<22.0.0	show Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.
gunicorn	20.1.0	<22.0.0	show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

gunicorn

20.1.0

<22.0.0

show

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

gunicorn

20.1.0

<22.0.0

show

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

pyup-update-pytest-cov-3.0.0-to-7.0.0

5 months, 1 week ago

08c8e301

Update pytest-cov from 3.0.0 to 7.0.0

Flask 2.2.2 and gunicorn 20.1.0 have known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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
gunicorn	20.1.0	<22.0.0	show Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.
gunicorn	20.1.0	<22.0.0	show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

gunicorn

20.1.0

<22.0.0

show

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

gunicorn

20.1.0

<22.0.0

show

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

pyup-update-pytest-cov-3.0.0-to-6.3.0

5 months, 1 week ago

bcccad46

Update pytest-cov from 3.0.0 to 6.3.0

Flask 2.2.2 and gunicorn 20.1.0 have known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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
gunicorn	20.1.0	<22.0.0	show Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.
gunicorn	20.1.0	<22.0.0	show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

gunicorn

20.1.0

<22.0.0

show

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

gunicorn

20.1.0

<22.0.0

show

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

pyup-update-pytest-7.1.3-to-8.4.2

5 months, 2 weeks ago

3ef1b581

Update pytest from 7.1.3 to 8.4.2

Flask 2.2.2 and gunicorn 20.1.0 have known security vulnerabilities.

Package	Installed	Affected	Info
Flask	2.2.2	<2.2.5 , >=2.3.0,<2.3.2	show 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
gunicorn	20.1.0	<22.0.0	show Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.
gunicorn	20.1.0	<22.0.0	show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

Package

Installed

Affected

Info

Flask

2.2.2

<2.2.5 , >=2.3.0,<2.3.2

show

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

gunicorn

20.1.0

<22.0.0

show

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

gunicorn

20.1.0

<22.0.0

show

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

pyup-update-flask-2.2.2-to-3.1.2

6 months ago

412a426f

Update flask from 2.2.2 to 3.1.2

gunicorn 20.1.0 has known security vulnerabilities.

Package	Installed	Affected	Info
gunicorn	20.1.0	<22.0.0	show Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.
gunicorn	20.1.0	<22.0.0	show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

Package

Installed

Affected

Info

gunicorn

20.1.0

<22.0.0

show

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

gunicorn

20.1.0

<22.0.0

show

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.