Summary
CSRF Vuln can expose user's QRcode
Workarounds
You can provide your own URL for fetching the QRcode by defining SECURITY_TWO_FACTOR_QRCODE_URL 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
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.
A victim's authenticated browser session is used to submit forged requests to an application that cannot distinguish them from legitimate ones. Typical impact: state-changing actions performed as the victim without their consent.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
This is fixed in the upcoming 4.0.0 release.
Frequently Asked Questions
- What is GHSA-FXQ4-R6MR-9X64? GHSA-FXQ4-R6MR-9X64 is a low-severity cross-site request forgery (CSRF) vulnerability in Flask-Security-Too (pip), affecting versions >= 3.2.0, < 3.4.5. It is fixed in 3.4.5. A victim's authenticated browser session is used to submit forged requests to an application that cannot distinguish them from legitimate ones.
- Which versions of Flask-Security-Too are affected by GHSA-FXQ4-R6MR-9X64? Flask-Security-Too (pip) versions >= 3.2.0, < 3.4.5 is affected.
- Is there a fix for GHSA-FXQ4-R6MR-9X64? Yes. GHSA-FXQ4-R6MR-9X64 is fixed in 3.4.5. Upgrade to this version or later.
- Is GHSA-FXQ4-R6MR-9X64 exploitable, and should I be worried? Whether GHSA-FXQ4-R6MR-9X64 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-FXQ4-R6MR-9X64 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-FXQ4-R6MR-9X64? Upgrade
Flask-Security-Tooto 3.4.5 or later.