Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Flask-Security-Too 5.8.0's OAuth reauthentication flow can mark a session as fresh after verifying an OAuth account that belongs to a different user. If an attacker can operate an already-authenticated but stale victim session, they can complete OAuth verification using their own OAuth identity. The victim session is then treated as recently reauthenticated, allowing freshness-protected account actions to proceed. This was reproduced against the built-in /change-username route. Details The issue is in the OAuth verification callback. oauthresponsecommon() resolves the OAuth provider identity to a Flask-Security user: - flasksecurity/oauthglue.py:101-108 oauthverifyresponse() then accepts any resolved user and updates the current session freshness timestamp: - flasksecurity/oauthglue.py:182-214 - flasksecurity/oauthglue.py:201-204 The missing check is that the OAuth-resolved user must match the current authenticated session user. In the failing case: - current session…
Recommended action: Upgrade to 5.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An open redirect vulnerability in the python package Flask-Security-Too <=5.3.2 allows attackers to redirect unsuspecting users to malicious sites via a crafted URL by abusing the ?next parameter on the /login and /register routes. Flask-Security-Too contains logic to validate that the URL specified within the next parameter is either relative or has the same network location as the requesting URL in an attempt to prevent open redirections. Previously known examples that bypassed the validation logic such as https://example/login?next=\\\\\\github.com were patched in version 4.1.0 However, examples such as https://example/login?next=/\\github.com and https://example/login?next=\\/github.com were discovered due to how web browsers normalize slashes in URLs, which makes the package vulnerable through version <=5.3.2 Additionally, with Werkzeug =2.1.0 the autocorrectlocationheader configuration was changed to False - which means that location headers in redirects are relative by…
Recommended action: Upgrade to 5.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Flask-Security allows redirects after many successful views (e.g. /login) by honoring the ?next query param. There is code in FS to validate that the url specified in the next parameter is either relative OR has the same netloc (network location) as the requesting URL. This check utilizes Pythons urlsplit library. However many browsers are very lenient on the kind of URL they accept and 'fill in the blanks' when presented with a possibly incomplete URL. As a concrete example - setting http://login?next=\\\github.com will pass FS's relative URL check however many browsers will gladly convert this to http://github.com. Thus an attacker could send such a link to an unwitting user, using a legitimate site and have it redirect to whatever site they want. This is considered a low severity due to the fact that if Werkzeug by default ALWAYS ensures that the Location header is absolute - thus making this attack vector mute. It is possible for application writers to modify this default…
Recommended action: Upgrade to 4.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When a user is setting up two-factor authentication using an authenticator app, a QRcode is generated and made available via a GET request to /tf-qrcode. Since GETs do not have any CSRF protection, it is possible a malicious 3rd party could access the QRcode and therefore gain access to two-factor authentication codes. Note that the /tf-qrcode endpoint is ONLY accessible while the user is initially setting up their device. Once setup is complete, there is no vulnerability. Patches This is fixed in the upcoming 4.0.0 release. Workarounds You can provide your own URL for fetching the QRcode by defining SECURITYTWOFACTORQRCODEURL and providing your own implementation (that presumably required a POST with CSRF protection). This would require changing the two-factor setup template as well. References None. For more information If you have any questions or comments about this advisory: Read this pull request: #423
Recommended action: Upgrade to 3.4.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Issue The /login and /change endpoints can return the authenticated user's authentication token in response to a GET request. Since GET requests aren't protected with a CSRF token, this could lead to a malicious 3rd party site acquiring the authentication token. Patches Version 3.4.5 and soon to be released 4.0.0 are patched. Workarounds If you aren't using authentication tokens - you can set the SECURITYTOKENMAXAGE to "0" (seconds) which should make the token unusable. References None
Recommended action: Upgrade to 3.4.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.