CVE-2026-4277

What it actually does

This is an authorization bypass in Django’s admin interface affecting GenericInlineModelAdmin. When inline generic model instances are submitted through crafted admin POST data, Django versions 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30 do not correctly enforce the user’s permission to add those inline objects. As a result, a user who can reach the relevant admin workflow may be able to create related generic inline records they are not authorized to add. Depending on how the affected application uses those inline models, this can lead to unauthorized data creation, privilege-impacting state changes, data integrity compromise, and potential exposure or manipulation of sensitive application records.

Why it matters to the business

Applications using the Django admin with generic inline models may allow unauthorized creation of records through forged form submissions. In business terms, this can undermine administrative access controls, allow improper changes to operational data, and create audit or compliance issues where duties are separated by role. The high CVSS score indicates serious potential impact if the affected admin functionality protects sensitive workflows, although the currently low EPSS and absence from CISA KEV suggest there is not yet strong evidence of broad exploitation. Unsupported Django branches, including older 5.0.x, 4.1.x, and 3.2.x series, were not evaluated and may also be affected, increasing risk for organizations running end-of-life versions.

How an attack unfolds

An attacker first identifies a Django application exposing the admin interface and determines whether any admin views use GenericInlineModelAdmin for related objects. The attacker then obtains the ability to submit admin POST requests for a parent object, either through legitimate low-privileged admin access, compromised credentials, or another route that permits authenticated interaction with the admin form. Instead of relying on the rendered form controls, the attacker crafts or modifies the POST body to include inline formset fields for a generic inline model they do not have add permission for. Vulnerable Django versions fail to enforce the add permission during submission of the forged inline data and accept the new inline object. The attacker can repeat this to create unauthorized related records, alter application state, or introduce data that later affects business logic, approvals, content, permissions, or downstream processing.

How to fix it

Upgrade Django to a fixed release: 6.0.4 or later for the 6.0 series, 5.2.13 or later for the 5.2 series, and 4.2.30 or later for the 4.2 LTS series. If running unsupported Django versions such as 5.0.x, 4.1.x, or 3.2.x, migrate to a supported fixed branch because those series were not evaluated and may be affected. As interim mitigation, restrict access to the Django admin interface to trusted networks or VPNs, enforce MFA for administrative users, review and minimize admin permissions, remove or disable affected GenericInlineModelAdmin usage where feasible, and add application-level validation around sensitive inline model creation. Do not rely solely on hiding inline form controls in the UI; authorization must be enforced server-side.

How to confirm the fix worked

Confirm the installed Django version reports 6.0.4 or later, 5.2.13 or later, or 4.2.30 or later, depending on the branch in use. Review dependency manifests and runtime package inventories to ensure no vulnerable Django version remains in production, build, or container images. Identify admin classes using GenericInlineModelAdmin or generic inline subclasses and verify users without add permission cannot create inline objects by submitting crafted POST formset data. A practical validation test is to create a low-privileged admin account with access to a parent admin object but without add permission for the inline model, submit a forged inline formset POST, and confirm the request is rejected or the inline object is not created. Also confirm audit logs show expected permission-denied behavior after patching.

Typical attack path

1. Identify a Django application exposing the administrative interface.
2. Find or infer admin pages that use generic inline model relationships.
3. Obtain the ability to submit admin POST requests, commonly through a low-privileged admin account or compromised admin session.
4. Capture a legitimate admin form submission involving inline formsets.
5. Modify the POST body to add extra generic inline form entries, including management form fields such as TOTAL_FORMS and inline object fields.
6. Submit the forged POST request to the vulnerable admin endpoint.
7. Confirm that unauthorized inline model instances were created despite the account lacking add permission for those inline objects.
8. Use the unauthorized records to manipulate application workflows, data visibility, approvals, content, or other business logic tied to the inline model.

How to detect it

To determine whether exploitation already occurred, focus on Django admin access logs, web server logs, application audit logs, and database or model-level change history for admin-created objects. Look for POST requests to /admin/ endpoints that include inline formset management fields and result in creation of generic inline model records by users who did not have add permission for the inline model at the time. Compare admin log entries for object additions against the user’s effective permissions and group memberships. Investigate unusual increases in inline form counts, repeated POST failures followed by successful submissions, admin edits where only inline records changed, and requests containing generic relation fields such as content_type and object_id. If threat intelligence later identifies specific actors or campaigns, pivot on their infrastructure, user agents, and credential-use patterns; none are provided for this CVE at this time. Because the vulnerability involves abuse of legitimate admin POST traffic, detection is most reliable when correlating HTTP logs, Django admin LogEntry records, authentication events, and application-specific object creation audit trails.

• POST /admin/
• TOTAL_FORMS=
• INITIAL_FORMS=
• MAX_NUM_FORMS=
• content_type=
• object_id=
• _save=
• _continue=
• django_admin_log
• GenericInlineModelAdmin

What your security team should do

• Prioritize upgrading all supported Django deployments to 6.0.4, 5.2.13, or 4.2.30 or later.
• Immediately identify applications using Django admin GenericInlineModelAdmin or generic inline subclasses and treat them as the highest-priority exposure candidates.
• Move any application on unsupported Django branches to a supported fixed release rather than attempting to remain on an unassessed version.
• Restrict administrative interfaces to trusted access paths and require MFA for admin users.
• Review admin permissions for least privilege, especially accounts that can edit parent objects with generic inline relationships.
• Search logs and audit trails for suspicious admin POST submissions that created inline records by users lacking corresponding add permissions.
• Add or verify server-side authorization checks for sensitive model creation paths outside the Django admin as defense in depth.
• Monitor for newly published exploit details because the vulnerability has a high severity rating even though public exploit maturity is currently listed as none.