django.contrib.auth.forms.AuthenticationForm in Django 2.0 before 2.0.2, and 1.11.8 and 1.11.9, allows remote attackers to obtain potentially sensitive information by leveraging data exposure from the confirm_login_allowed() method, as demonstrated by discovering whether a user account is inactive.

The remote Redhat Enterprise Linux 8 host has one or more packages installed that are affected by a vulnerability that has been acknowledged by the vendor but will not be patched.

  - django: Information leakage in AuthenticationForm (CVE-2018-6188)

Note that Nessus has not tested for this issue but has instead relied on the package manager's report that the package is installed.

update to 1.11.10, fix for CVE-2018-6188: Information leakage in AuthenticationForm

Note that Tenable Network Security has extracted the preceding description block directly from the Fedora update system website.
Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

It was discovered that Django incorrectly handled certain requests. An attacker could possibly use this to access sensitive information.
(CVE-2017-12794, CVE-2018-6188).

Note that Tenable Network Security has extracted the preceding description block directly from the Ubuntu security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

Django release notes :

CVE-2018-6188: Information leakage in AuthenticationForm

A regression in Django 1.11.8 made AuthenticationForm run its confirm_login_allowed() method even if an incorrect password is entered. This can leak information about a user, depending on what messages confirm_login_allowed() raises. If confirm_login_allowed() isn't overridden, an attacker enter an arbitrary username and see if that user has been set to is_active=False. If confirm_login_allowed() is overridden, more sensitive details could be leaked.

This issue is fixed with the caveat that AuthenticationForm can no longer raise the 'This account is inactive.' error if the authentication backend rejects inactive users (the default authentication backend, ModelBackend, has done that since Django 1.10). This issue will be revisited for Django 2.1 as a fix to address the caveat will likely be too invasive for inclusion in older versions.

ID	Name	Product	Family	Severity
198749	RHEL 8 : django (Unpatched Vulnerability)	Nessus	Red Hat Local Security Checks	high
106822	Fedora 27 : python-django (2018-2c612c6d92)	Nessus	Fedora Local Security Checks	high
106675	Ubuntu 17.10 : python-django vulnerabilities (USN-3559-1)	Nessus	Ubuntu Local Security Checks	high
106599	FreeBSD : Django -- information leakage (d696473f-9f32-42c5-a106-bf4536fb1f74)	Nessus	FreeBSD Local Security Checks	high

Detections

Analytics

CVE-2018-6188

high

Tenable Plugins

high

high

high

high