Safety CI > CarlosLannister/IHS

pyup-update-flask-socketio-4.2.1-to-5.6.1

1 month, 4 weeks ago

1e0e6f57

Update flask-socketio from 4.2.1 to 5.6.1

Flask 1.1.1 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	1.1.1	<3.1.3	show Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.
Flask	1.1.1	<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

1.1.1

<3.1.3

show

Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.

Flask

1.1.1

<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-flask-1.1.1-to-3.1.3

2 months ago

1706e6a4

Update flask from 1.1.1 to 3.1.3

No dependencies with known security vulnerabilities.

snyk-fix-885d68c9ad3227e94dae3169a8b5a3e9

3 months ago

8c3d7ac4

fix: waterTower/requirements.txt to reduce vulnerabilities The following vulnerabilities are fixed

Flask 1.1.1 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	1.1.1	<3.1.3	show Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.
Flask	1.1.1	<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

1.1.1

<3.1.3

show

Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.

Flask

1.1.1

<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-flask-socketio-4.2.1-to-5.6.0

3 months, 3 weeks ago

adc2e2db

Update flask-socketio from 4.2.1 to 5.6.0

Flask 1.1.1 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	1.1.1	<3.1.3	show Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.
Flask	1.1.1	<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

1.1.1

<3.1.3

show

Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.

Flask

1.1.1

<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

snyk-fix-a60c5d1fce2eecf9edeeef45f62fea01

4 months, 2 weeks ago

589edb32

fix: waterTower/requirements.txt to reduce vulnerabilities The following vulnerabilities are fixed

Flask 1.1.1 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	1.1.1	<3.1.3	show Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.
Flask	1.1.1	<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

1.1.1

<3.1.3

show

Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.

Flask

1.1.1

<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

snyk-fix-13a62ef5f7d88b07b102785ed69db5ed

6 months, 1 week ago

ce7856b5

fix: waterTower/requirements.txt to reduce vulnerabilities The following vulnerabilities are fixed

Flask 1.1.1 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	1.1.1	<3.1.3	show Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.
Flask	1.1.1	<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

1.1.1

<3.1.3

show

Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.

Flask

1.1.1

<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-flask-1.1.1-to-3.1.2

8 months ago

c943ac20

Update flask from 1.1.1 to 3.1.2

No dependencies with known security vulnerabilities.

pyup-update-flask-1.1.1-to-3.1.1

11 months, 1 week ago

65a7e7b0

Update flask from 1.1.1 to 3.1.1

No dependencies with known security vulnerabilities.

pyup-update-flask-socketio-4.2.1-to-5.5.1

1 year, 3 months ago

ec82c393

Update flask-socketio from 4.2.1 to 5.5.1

Flask 1.1.1 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	1.1.1	<3.1.3	show Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.
Flask	1.1.1	<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

1.1.1

<3.1.3

show

Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.

Flask

1.1.1

<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-flask-socketio-4.2.1-to-5.5.0

1 year, 4 months ago

850636b8

Update flask-socketio from 4.2.1 to 5.5.0

Flask 1.1.1 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	1.1.1	<3.1.3	show Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.
Flask	1.1.1	<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

1.1.1

<3.1.3

show

Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.

Flask

1.1.1

<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-flask-1.1.1-to-3.1.0

1 year, 5 months ago

718c455a

Update flask from 1.1.1 to 3.1.0

No dependencies with known security vulnerabilities.

snyk-fix-924a63fe1cbf11be6ccb3bf34c450737

1 year, 5 months ago

98c89f66

fix: waterTower/requirements.txt to reduce vulnerabilities The following vulnerabilities are fixed

Flask 1.1.1 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	1.1.1	<3.1.3	show Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.
Flask	1.1.1	<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

1.1.1

<3.1.3

show

Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.

Flask

1.1.1

<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-flask-socketio-4.2.1-to-5.4.1

1 year, 6 months ago

70db948f

Update flask-socketio from 4.2.1 to 5.4.1

Flask 1.1.1 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	1.1.1	<3.1.3	show Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.
Flask	1.1.1	<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

1.1.1

<3.1.3

show

Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.

Flask

1.1.1

<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-flask-socketio-4.2.1-to-5.4.0

1 year, 6 months ago

06e68a4b

Update flask-socketio from 4.2.1 to 5.4.0

Flask 1.1.1 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	1.1.1	<3.1.3	show Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.
Flask	1.1.1	<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

1.1.1

<3.1.3

show

Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.

Flask

1.1.1

<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-flask-socketio-4.2.1-to-5.3.7

1 year, 7 months ago

52d2fbdc

Update flask-socketio from 4.2.1 to 5.3.7

Flask 1.1.1 has known security vulnerabilities.

Package	Installed	Affected	Info
Flask	1.1.1	<3.1.3	show Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.
Flask	1.1.1	<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

1.1.1

<3.1.3

show

Affected versions of the Flask package are vulnerable to Information Disclosure due to missing cache-variation headers when the session object is accessed via certain code paths. In Flask’s session handling, accessing flask.session is intended to set a Vary: Cookie response header, but session key-only access patterns (such as using the Python in operator to test for a key without reading or mutating session values) can bypass the logic that adds the header.

Flask

1.1.1

<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