CVE-2026-7666: 
Django vulnerability analysis and mitigation

CVE-2026-7666 is an information disclosure vulnerability in Django's SMTP email backend (django.core.mail.backends.smtp.EmailBackend) that allows on-path network attackers to intercept email content in cleartext. The flaw arises because Django fails to prevent reuse of a partially-initialized SMTP connection after a failed STARTTLS handshake when fail_silently=True is configured. Affected versions are Django 6.0 before 6.0.6 and 5.2 before 5.2.15; earlier unsupported series (5.0.x, 4.1.x, 3.2.x) were not evaluated but may also be affected. It was disclosed on June 3, 2026, and credited to reporter Kasper Dupont. The vulnerability carries a CVSS v3.1 base score of 3.1 (Low) and a CVSS v4.0 base score of 2.3 (Low) (GitHub Advisory, Django Security Releases).

The root cause is classified under CWE-319 (Cleartext Transmission of Sensitive Information) and CWE-325 (Missing Cryptographic Step). When fail_silently=True is set on Django's EmailBackend, a failed STARTTLS negotiation does not terminate the connection; instead, the partially-initialized connection is reused and email is transmitted over an unencrypted channel without raising an exception. An on-path attacker positioned between the Django application server and the SMTP relay can passively intercept this cleartext traffic. Exploitation requires network positioning (high attack complexity) and passive user interaction (an email being sent), making opportunistic mass exploitation unlikely (GitHub Advisory, Red Hat Bugzilla).

Successful exploitation allows an on-path network attacker to read the full content of emails sent through Django's SMTP backend, including potentially sensitive data such as password reset tokens, account notifications, or other application-generated messages. There is no impact on integrity or availability, and the scope is limited to the vulnerable system's email communications. Lateral movement is not directly enabled by this vulnerability, but exposed email content (e.g., authentication tokens) could facilitate further account compromise (GitHub Advisory, Django Security Releases).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure. The EPSS score is approximately 0.018% (2nd percentile), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported (GitHub Advisory).

1. Network Positioning: The attacker establishes an on-path (man-in-the-middle) position between the Django application server and its configured SMTP relay, using techniques such as ARP spoofing, BGP hijacking, or rogue network device placement on a shared network segment.
2. Trigger STARTTLS Failure: The attacker intercepts or disrupts the STARTTLS handshake between the Django server and the SMTP relay, causing the TLS upgrade to fail (e.g., by stripping the STARTTLS response or injecting a protocol error).
3. Connection Reuse: Because fail_silently=True is configured in Django's EmailBackend, the failed handshake does not raise an exception or abort the connection. Django reuses the partially-initialized, unencrypted connection.
4. Cleartext Interception: The attacker captures the subsequent SMTP session traffic using a packet capture tool (e.g., Wireshark, tcpdump), reading the full email content transmitted in cleartext over the network (GitHub Advisory, Django Security Releases).

• Network: Unencrypted SMTP traffic (port 25 or 587) observed from the Django application server after a STARTTLS command sequence that does not complete successfully; absence of TLS handshake records following STARTTLS in packet captures.
• Network: Unexpected ARP table changes or duplicate MAC addresses on the network segment hosting the Django server or SMTP relay, potentially indicating ARP spoofing.
• Logs: SMTP server logs showing connections that initiated STARTTLS but reverted to plaintext sessions; Django application logs showing no TLS-related errors despite fail_silently=True being set.
• Logs: Mail transfer agent (MTA) logs recording email delivery without TLS encryption from the Django server.

Upgrade Django to version 6.0.6 or 5.2.15, which contain the fix for this vulnerability (Django Security Releases, Django 5.2.15 Release Notes). As a configuration-level workaround, avoid setting fail_silently=True on EmailBackend in production environments where email confidentiality is required, so that TLS failures raise exceptions and prevent cleartext fallback. Additionally, enforce TLS-only SMTP connections at the network or MTA level (e.g., require SMTPS on port 465 or enforce mandatory TLS on port 587) to prevent cleartext email transmission regardless of application-layer behavior. Organizations running unsupported Django series (5.0.x, 4.1.x, 3.2.x) should treat those as potentially affected and prioritize upgrading to a supported, patched release (Red Hat Bugzilla).

The Django project acknowledged the issue and credited Kasper Dupont for responsible disclosure in its official security release announcement (Django Security Releases). Red Hat tracked the issue as low severity in its Bugzilla system, and SUSE issued a security update (SUSE-SU-2026:2318-1) for affected packages. The vulnerability was also picked up by OpenSUSE security announcements and Fedora advisories, reflecting standard downstream Linux distribution response. Community reaction has been muted given the low CVSS score and absence of public exploits.