CVE-2026-15920

The CVSS 6.1 score for this stored XSS in Django's admin URLField display fundamentally misrepresents the actual risk. The vulnerability lives in `display_for_field()`, a utility function that renders URL values in the Django admin interface without re-escaping them—under the implicit assumption that data already validated through forms is safe. That assumption breaks whenever data enters URLField columns through any path that bypasses Django's form validation: bulk imports, data migrations, fixture loading, deserialized payloads from third-party integrations, or direct queryset writes. This precondition is far more common than the CVSS suggests. Django actively encourages migrations, fixture usage, and ORM-based bulk operations as idiomatic patterns. Developers routinely port data from legacy systems, external APIs, or deserialized sources into URLField columns without passing through ModelForm validation. The framework tells you to use forms for validation and migrations for data operations—but never surfaces the security tension between these patterns. The severity disconnect stems from what admin context actually means. Admin users aren't regular users—they control Django's auth system, site settings, user permissions, and often database credentials stored in settings.py. Stored XSS against an admin creates a direct path to session cookie harvesting, admin account takeover, permission modification, and complete application compromise. One admin session is a skeleton key to the entire stack. The CVSS treats this as a medium integrity issue; it's actually a privilege escalation vector to full application control. The rendering layer in `display_for_field()` assumes data safety that only holds under the happy-path form validation flow. When data bypasses that flow, the defense-in-depth breaks at output time rather than input time. This means the admin rendering layer needs its own contextual escaping independent of upstream validation—not as a secondary measure, but as the primary invariant. For detection, the real indicator isn't CVSS or EPSS scores. Check whether your application has any URLField columns populated outside Django's form layer. If yes, assume compromise is possible and investigate: review what those URLField columns currently contain, rotate any admin sessions active since the data entered the system, and audit admin action logs for unauthorized permission changes or settings modifications. The patch fixes `display_for_field()`, but the architectural gap remains. Django's admin rendering layer treats 'data is safe' as the default state to override rather than 'data is dangerous' as the invariant to enforce. This is the same failure pattern that produced prior admin display vulnerabilities (CVE-2013-4249, CVE-2014-0473, CVE-2016-2512)—each patched individually while the cultural gap persisted. A systematic audit of every admin display utility operating on the same implicit trust assumption would be prudent, because this family of bugs has a track record of spawning follow-on disclosures.

Reviewed through automated stages and approved by a human before publication.