Track vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
7.5
python-flask 1.1.1-4 may expose session cookies to other users
published 3 years ago
Summary
If a Flask web app using version 1.1.1-4 runs behind a caching proxy that does not remove cookies, the proxy can store a response and later deliver another user's session cookie to a different visitor. This can happen when the app sets permanent sessions, does not modify the session during a request, and does not mark the page as private. Upgrade Flask to a newer release (2.2.5 or later) to stop the proxy from caching these responses.
What to do
The CVE record does not list a fixed version. Check the vendor's site or the advisory links below - a fix may already be released.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| Azure Linux:3 | azure | python-flask | <= 1.1.1-4 |
Original advisory text
CVE-2023-30861 affecting package python-flask 1.1.1-4
Flask is a lightweight WSGI web application framework. 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. This issue has been fixed in versions 2.3.2 and 2.2.5.
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. This issue has been fixed in versions 2.3.2 and 2.2.5.
References
Internet-facing
14 days
Internal
60 days
- Not known to be exploited
- Can be exploited automatically (estimated)
- Gives an attacker partial control (estimated)
Timeline
Published2 May 2023
Updated23 Sep 2026
First seen23 Sep 2026
Sources
AZL-44718 · OSV
Track software like this
Free during beta