CVE-2026-4292

What it actually does

Django admin changelist views that use `ModelAdmin.list_editable` fail to properly restrict formset behavior, allowing a highly privileged authenticated admin user to forge POST data that creates new model instances from a changelist form. The vulnerability affects Django 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30; unsupported series such as 5.0.x, 4.1.x, and 3.2.x were not evaluated and may also be affected. The impact is limited to integrity: an attacker must already have admin access to the relevant Django admin interface, but can cause unauthorized object creation through a code path intended only for editing existing rows.

Why it matters to the business

This issue can allow an already-privileged admin account, or an attacker who has taken over one, to create unintended application records through the Django admin interface. In business terms, this could result in unauthorized configuration changes, fraudulent records, workflow manipulation, or data integrity problems, depending on which models expose editable fields in admin changelists. The CVSS score is low and EPSS is very low, with no known KEV listing or mature public exploitation indicated, but applications that rely on Django admin for sensitive operational data should still patch because admin account compromise is a common post-compromise scenario.

How an attack unfolds

An attacker first needs authenticated access to the Django admin site with sufficient privileges to view and edit a model whose `ModelAdmin` configuration uses `list_editable`. The attacker identifies an affected changelist page, observes the form fields and management form parameters used by Django admin, and submits a crafted POST request that includes manipulated formset data representing an extra object. Because vulnerable Django versions incorrectly trust the forged changelist form data, the admin view may create a new model instance even though the changelist editing workflow should only update existing objects. The attacker can then use the newly created object to alter application state, insert unauthorized business records, or prepare follow-on abuse depending on the affected model and application logic.

How to fix it

Upgrade Django to a fixed supported release: 6.0.4 or later for the 6.0 series, 5.2.13 or later for the 5.2 LTS series, or 4.2.30 or later for the 4.2 LTS series. If running an unsupported Django series such as 5.0.x, 4.1.x, or 3.2.x, migrate to a supported fixed branch because those versions were not evaluated and may be affected. As interim mitigation, review Django admin classes and remove or disable `list_editable` on sensitive models until patching is complete. Restrict access to the Django admin interface using strong authentication, MFA, IP allowlisting or VPN, least-privilege staff permissions, and session monitoring. Review admin permissions so users only have access to models and fields required for their role.

How to confirm the fix worked

Confirm the deployed Django package version is 6.0.4 or later, 5.2.13 or later, or 4.2.30 or later. Use package-manager output such as `python -m django --version`, `pip show Django`, `pip freeze`, lockfiles, container image manifests, and software composition analysis results to verify the runtime version, not only the source repository version. Identify admin classes using `list_editable` and confirm they run on a fixed Django release. In a non-production test environment, attempt to submit forged changelist formset POST data that would create an extra object; the fixed version should reject the request or avoid creating a new instance. Also verify that unsupported Django branches have been upgraded rather than relying on untested assumptions.

Typical attack path

1. Obtain valid Django admin credentials or compromise an existing highly privileged admin session.
2. Find a Django admin model changelist that uses `ModelAdmin.list_editable`.
3. Review the changelist form structure and identify editable fields, object identifiers, and Django formset management parameters.
4. Send a forged POST request to the admin changelist endpoint with manipulated formset data that represents a new object rather than only edits to existing objects.
5. Confirm the new model instance was created through the admin interface or application behavior.
6. Use the unauthorized record to influence business logic, configuration, permissions, workflow state, or downstream processing.

How to detect it

To determine whether this was already exploited, focus on Django admin access logs, web server logs, application audit logs, Django admin `LogEntry` records, and database-level creation timestamps for models exposed through admin changelists with `list_editable`. Look for POST requests to Django admin changelist URLs, which typically follow `/admin/<app_label>/<model_name>/`, followed by unexpected object creation events for the same model. Pay special attention to admin users who created records through unusual source IPs, unfamiliar user agents, impossible travel patterns, abnormal times of day, or sessions that recently changed authentication state. Compare created records against expected business workflows, approval trails, and application-level audit history. Because exploitation uses legitimate admin endpoints and forged form data, there may be no malware-like artifact; detection depends on correlating admin POST activity with unexpected creation of model instances where only edits were expected.

• POST /admin/
• /admin/
• django.contrib.admin.models.LogEntry
• action_flag=ADDITION
• change_message
• list_editable
• TOTAL_FORMS
• INITIAL_FORMS
• MIN_NUM_FORMS
• MAX_NUM_FORMS

What your security team should do

• Patch Django to 6.0.4+, 5.2.13+, or 4.2.30+ as the primary remediation.
• Prioritize applications where Django admin is internet-accessible, used for sensitive business records, or has many staff/admin users.
• Inventory all Django admin configurations using `ModelAdmin.list_editable`, especially on models that affect payments, access control, approvals, inventory, pricing, or operational workflows.
• If immediate patching is not possible, temporarily remove `list_editable` from sensitive admin models and restrict Django admin access to trusted networks.
• Review privileged Django admin accounts for compromise, weak authentication, excessive permissions, and missing MFA.
• Audit recent admin POST activity and model creation events for unexpected records created through admin changelist endpoints.
• Move unsupported Django versions to a supported fixed branch; do not assume unsupported releases are safe.
• Add regression tests for sensitive admin changelist views to ensure forged formset data cannot create new objects.