EUVD-2026-93396
GHSA-x869-hccf-fv7r
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Impact | This is a genuinely moderate-severity authorization flaw (CWE-639), not a critical one, and the signals are internally consistent. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N = 4.3) indicates a network-reachable but privilege-requiring issue (PR:L) with only low integrity impact and no confidentiality or availability loss, which matches Django's own 'moderate' rating under its security policy. No EPSS score, KEV listing, or public exploit was supplied in the intelligence, so there is no evidence of active or at-scale exploitation - this reads as a defense-in-depth fix rather than an emergency. The real limiting factor understated by the raw CVSS is configuration dependence: exploitation only applies to the narrow case where a model's primary key is a form-editable field (OneToOneField/parent-link, natural key, or UUID), and applications using the default AutoField/BigAutoField PK are entirely unaffected. Net priority: patch during normal maintenance; prioritize sooner only if you operate inline/model formsets over models with editable primary keys exposed to semi-trusted authenticated users. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 06, 2026
Authenticated users who are permitted to submit a Django model formset can delete database rows outside that formset's limiting queryset - without holding any permission on the targeted object - by forging management-form POST data when the affected model's primary key is editable through the form. The flaw is an authorization bypass through a user-controlled key (CWE-639) in django.forms.models.BaseModelFormSet.save_existing_objects(), rated CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) with integrity-only impact; it affects Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18, while models using the default AutoField/BigAutoField primary key are not affected. No public exploit code identified at time of analysis, and there is no confirmed active exploitation (not in CISA KEV); this is a genuinely moderate-severity authorization flaw and the signals are internally consistent.
RemediationAI
Vendor-released patch: upgrade to Django 6.1.2, 6.0.9, or 5.2.18 respectively for the 6.1, 6.0, and 5.2 branches, as documented in the Django security release announcement (https://www.djangoproject.com/weblog/2026/oct/06/security-releases/) and the per-series release notes; the fix is the change to django/forms/models.py in upstream commits 83cbd21be57483e6b3eb6e4688a561c841aff75e, cce6c57ed30ea83725f9d6abb2fe5ee932bab107, b83ab92bc5474558b083a840ea4628b3261b2cfe, and ff27883ca055aa9ab23015b50674a5b10dfe5a41, so backporting that guard (not obj._is_pk_set() or obj._state.adding) is required for unsupported branches (5.1.x, 5.0.x, 4.2.x) that were not evaluated. If upgrading immediately is not possible, reduce exposure by ensuring the primary key is not an editable form field - exclude it from formset fields or mark it read-only - since formsets over models with a default AutoField/BigAutoField are unaffected, and by restricting which authenticated users may submit such formsets and validating that any submitted primary key values belong to the intended limiting queryset before calling save(); both controls constrain legitimate workflows that rely on client-supplied natural keys and require application-side code changes rather than a configuration switch. Because exploitation already requires an authenticated account with formset-submission rights (CVSS PR:L), tightening that authorization boundary is a viable compensating control, but it does not address the underlying flaw and should be treated as temporary until the patched release is deployed.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Django model formsets (django.forms.models.BaseModelFormSet and its inlineformset_factory/modelformset_factory derivatives) let developers expose a queryset-limited set of model instances for bulk editing. During save, save_existing_objects() iterates the submitted forms and must decide whether each form's instance belongs to the formset's limiting queryset; instances that were never fetched from that queryset are represented by newly constructed, unsaved objects. The vulnerable logic inferred ownership from the mere presence of a primary key on the instance, but _is_pk_set() can return True on a fresh instance when the primary key is a form field the client controls - for example a OneToOneField or parent link used as the primary key of an inline formset's model, or a natural key/UUID primary key included in fields. Because that forged key value is then trusted as proof of queryset membership, the downstream delete path (triggered by the '-DELETE' management-form field) acts on an out-of-queryset row. This is CWE-639, Authorization Bypass Through User-Controlled Key: an object reference supplied by the user is not re-validated against the caller's authorized set. Notably, models with the default AutoField/BigAutoField primary key are unaffected because such keys are not accepted as editable form fields. The upstream fix tightens the guard to if not obj._is_pk_set() or obj._state.adding: so that any unfetched/new instance is skipped, and regression tests confirm both that out-of-queryset deletion is blocked and that edit_only formsets can no longer be used to create forged instances.
Know when Django gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Primary rating from Vendor (DSF).
CVSS VectorVendor: DSF
Lifecycle Timeline
1DescriptionCVE.org
An issue was discovered in Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18. django.forms.models.BaseModelFormSet.save_existing_objects() used the presence of a primary key on a submitted form's instance as evidence that the instance belonged to the formset's limiting queryset. An object outside that queryset is represented by a newly constructed instance whose primary key can still be populated from submitted data when the model's primary key is a field accepted by the form, such as a OneToOneField or parent link used as the primary key of an inline formset's model, or a natural or UUID primary key included in the form's fields. This allows an authenticated user permitted to submit such a formset to delete rows outside the limiting queryset, without any permission on the targeted object, via forged management-form data marking an out-of-queryset object for deletion. Models using the default AutoField primary key are not affected. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Seonggwon Yoon for reporting this issue.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
The package python/cpython from 0 and before 3.6.13, from 3.7.0 and before 3.7.10, from 3.8.0 and before 3.8.8, from 3.9
In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for
An issue was discovered in Django 3.2 before 3.2.14 and 4.0 before 4.0.6. Rated critical severity (CVSS 9.8), this vulne
Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input
Django before 1.11.27, 2.x before 2.2.9, and 3.x before 3.0.1 allows account takeover. Rated critical severity (CVSS 9.8
An authentication/authorization bypass in the djust Python live-view framework (versions prior to 1.0.7) lets unauthenti
Unauthenticated arbitrary Python module import in djust before 1.0.7 lets any client that can reach the WebSocket or SSE
Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a
Cross-site scripting (XSS) vulnerability in the dismissChangeRelatedObjectPopup function in contrib/admin/static/admin/j
Forged content modification in django-page-cms through 2.0.13 lets unauthenticated remote attackers exploit five CSRF-ex
Cross-site request forgery in djust's Server-Sent-Events transport affects all versions prior to 1.0.7 and allows a cros
Unauthenticated remote attackers can read live Django view and session state and invoke server-side handlers through dju
Same technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Linux Enterprise Module for Package Hub 15 SP7 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.6 | Affected |
Exploit-DB