CVE-2020-15105

In Django Two-Factor Authentication, user passwords are stored in clear text in the Django session

MEDIUM
5.4
CVSS Score
Published: July 10, 2020 at 08:55 PM UTC
Updated: June 17, 2026 at 02:56 AM UTC
2 products affected across 2 vendorsDjango Two Factor AuthenticationTwo Factor Authentication Project Django Two Factor Authentication

Using django-two-factor-auth by Bouke?

Get instant alerts when new vulnerabilities affect django-two-factor-auth - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.4
Exploit prediction
EPSS 0.7%

Description

Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authentication code. This means that the password is stored in clear text in the session for an arbitrary amount of time, and potentially forever if the user begins the login process by entering their username and password and then leaves before entering their two-factor authentication code. The severity of this issue depends on which type of session storage you have configured: in the worst case, if you're using Django's default database session storage, then users' passwords are stored in clear text in your database. In the best case, if you're using Django's signed cookie session, then users' passwords are only stored in clear text within their browser's cookie store. In the common case of using Django's cache session store, the users' passwords are stored in clear text in whatever cache storage you have configured (typically Memcached or Redis). This has been fixed in 1.12. After upgrading, users should be sure to delete any clear text passwords that have been stored. For example, if you're using the database session backend, you'll likely want to delete any session record from the database and purge that data from any database backups or replicas. In addition, affected organizations who have suffered a database breach while using an affected version should inform their users that their clear text passwords have been compromised. All organizations should encourage users whose passwords were insecurely stored to change these passwords on any sites where they were used. As a workaround, wwitching Django's session storage to use signed cookies instead of the database or cache lessens the impact of this issue, but should not be done without a thorough understanding of the security tradeoffs of using signed cookies rather than a server-side session storage. There is no way to fully mitigate the issue without upgrading.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v < 1.12
Affected range stops below 1.12, so it looks safe — our inference, not a vendor statement
v < 1.12
Affected range stops below 1.12, so it looks safe — our inference, not a vendor statement

Remediation

No guide yet

No remediation guidance has been written for this CVE yet. What the record does show:

CVSS

5.4MEDIUMGitHub_M
Attack Vector
NETWORK
Complexity
HIGH
Privileges
LOW
User Interaction
REQUIRED
Scope
UNCHANGED
Confidentiality
HIGH
Integrity
LOW
Availability
NONE
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-312

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card