Django CVE-2026-113733

Exploitation requires an authenticated admin staff user holding only the 'view' permission on a user model that is EITHER not the configured AUTH_USER_MODEL, OR is an AUTH_USER_MODEL that inherits its password field from a concrete parent model through multi-table inheritance. Django's standard AUTH_USER_MODEL with its own password field is NOT affected, so this is a non-default custom-user-model deployment condition. Limiting factors: the attacker must already have valid staff credentials and admin access (PR:H), the admin site must expose the affected user model as read-only to that user, and the information gained is password hashes (not plaintext), which still require offline cracking to be useful.

This is a genuinely low-priority issue, and the signals are internally consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:H/UI:N/VC:L with VI:N/VA:N) describes an information-disclosure flaw limited to low confidentiality impact with no integrity or availability effect, and crucially requires high privileges (PR:H) - an already-authenticated staff user. The vendor itself rates it 'low' under the Django security policy, and vuln.today assigns a 'monitor' decision label, the lowest urgency tier. No EPSS score and no CISA KEV entry were provided, and there is no public exploit reference in the input, so there is nothing to suggest active or widespread exploitation. The only material caveat is scope: exploitation does not apply to Django's default User model - it needs a non-standard custom user model configuration (see exploitation_conditions) - so even the modest base score overstates risk for the typical deployment. There is no high-CVSS/low-real-risk contradiction here; both the raw score and all contextual signals agree this is a minor, privilege-gated disclosure.

An authenticated Django admin staff member who has been granted only the 'view' permission (not 'change') on a custom user model opens that user's read-only change form in the admin. Because display_for_field() failed to obfuscate the password field for non-AUTH_USER_MODEL user models (or an AUTH_USER_MODEL inheriting its password column from a concrete parent via multi-table inheritance), the form renders the full password hash instead of a masked placeholder, which the staff user can copy for offline cracking. No public exploit code is referenced; exploitation requires network access to the admin plus valid staff credentials (PR:H).