django CMS: Broken access control in page *Duplicate* allows reading the content of any page (cross-site / restriction bypass)
Impact
The only authorization gate on the duplicate flow is PageAdmin.has_add_permission,
which checks user_can_add_page(user, site) / user_can_add_subpage(...) — i.e. “may
this user create a page at all”. Nothing checks the user’s relationship to the page being
copied:
cms/admin/forms.py—DuplicatePageForm.source = ModelChoiceField(queryset=Page.objects.all(), widget=HiddenInput())spans every page in the database, on every site.cms/admin/forms.py—AddPageForm.__init__returns early when thesourcewidget is hidden, so the queryset is never narrowed to the user’s site/subtree.cms/admin/forms.py—AddPageForm.clean()validates only URL uniqueness;sourceis never validated against the user.cms/admin/pageadmin.py—duplicate()seedssourcefrom the URL only on GET; on POST the value comes entirely from the request body.cms/admin/forms.py—AddPageForm.save()→from_source()performssource.copy(..., permissions=False)and copies every placeholder and all plugins ofsourceinto a new page on the attacker’s site. Becausepermissions=Falsedrops the source’s view restrictions, the resulting copy is fully readable by the attacker.
This crosses a real privilege boundary: a staff user restricted (via CMS_PERMISSION) to
their own site or subtree can exfiltrate the content of restricted pages and of pages
belonging to other tenants.
Read-back is trivial (verified): the copy is created on the attacker’s site and, because
copy(..., permissions=False) strips the source’s view restrictions, the new page is
unrestricted. user_can_view_page() then returns True for it (unrestricted +
PUBLIC_FOR), so the attacker — or even an anonymous visitor — can read the duplicated
content directly from the front end. No further permission on the new page is required.
Proof of concept
- Log in as a staff user
attackerwho has add page permission but no view/change permission on a target (secret / other-site) pageSECRET_ID. - Send (the URL
<id>only needs to be aPageContentthe attacker can already see — e.g. one of their own pages; the victim id goes in the POST body):
POST /admin/cms/pagecontent/<MY_OWN_PAGECONTENT_ID>/duplicate/ HTTP/1.1
Cookie: sessionid=<attacker session>
Content-Type: application/x-www-form-urlencoded
csrfmiddlewaretoken=...&title=x&slug=x&language=en&source=<SECRET_ID>
- A new, unrestricted page is created under the attacker’s site containing a verbatim copy of the secret page’s plugins, which the attacker can now preview/edit/read.
Patches
Enforce an object-level permission check on source:
class DuplicatePageForm(AddPageForm):
source = forms.ModelChoiceField(
queryset=Page.objects.all(),
required=True,
widget=forms.HiddenInput(),
)
def clean_source(self):
source = self.cleaned_data.get("source")
if source and not user_can_view_page(self._user, source):
raise ValidationError(_("You do not have permission to copy this page."))
return source
(user_can_view_page is imported from cms.utils.page_permissions.)
Workarounds
Until patched, restrict access to the cms.add_page permission to fully-trusted staff, or
disable the duplicate action for delegated/limited editors.
References
cms/admin/pageadmin.py—duplicate(),has_add_permission(),get_urls()cms/admin/forms.py—DuplicatePageForm,AddPageForm.__init__/clean/save/from_source- Regression tests:
cms/tests/test_forms.py::DuplicatePageFormSecurityTestCase
Czego dotyczy
Kliknij technologię, aby zobaczyć wszystkie dotyczące jej podatności.
| Platforma | Paczka | Podatne wersje | Poprawka w wersji |
|---|---|---|---|
| Python (PyPI) | django-cms | < 5.0.9 | 5.0.9 |
Odnośniki
- https://github.com/django-cms/django-cms/security/advisories/GHSA-6x92-6vx4-5fwr
- https://github.com/django-cms/django-cms/pull/8713
- https://github.com/django-cms/django-cms/commit/3e1ccf7573eb1a74ebbbfaaa812c1f5cadf14e6c
- https://github.com/django-cms/django-cms
- https://github.com/django-cms/django-cms/releases/tag/5.0.9
- https://pypi.org/project/django-cms
- https://github.com/advisories/GHSA-6x92-6vx4-5fwr
- https://nvd.nist.gov/vuln/detail/CVE-2026-63003
- Wektor CVSS
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N- Słabość (CWE)
CWE-639, CWE-862- Platforma
- Python (PyPI)
- Paczka
django-cms- Ujawniono
- 20.08.2026
- Aktualizacja
- 11.10.2026 15:18
Źródła i licencje
OSV / GitHub Advisory Database - PYSEC-2026-3821 - PyPA Advisory Database; CC BY 4.0
OSV / GitHub Advisory Database - GHSA-6x92-6vx4-5fwr - CC BY 4.0
Historia podatności: django-cms
Wszystkie opisane podatności tej paczki (Python (PyPI)), od najnowszej. Widać, czy to jednorazowa wpadka, czy paczka, której trzeba pilnować.
- Wszystkich wpisów
- 10
- Pierwsza → ostatnia
- 08.2017 08.2026
- Bez poprawki
- 0
- Wykorzystywana w atakach
- 0
Rozkład istotności
- Wysoka 2
- Średnia 8
Ujawnienia w latach
- 2017: 1
- 2018: 0
- 2019: 0
- 2020: 0
- 2021: 0
- 2022: 1
- 2023: 0
- 2024: 1
- 2025: 0
- 2026: 7
-
django CMS: Broken access control in page *Duplicate* allows reading the content of any page (cross-site / restriction bypass) ten wpis
Dowiedz się, które podatności dotyczą Twojej aplikacji
Po podłączeniu integracji DockRay i włączeniu raportowania oprogramowania DockRay porównuje zgłoszone wersje komponentów ze znanymi podatnościami i powiadamia o potwierdzonych dopasowaniach. Zakres zależy od obsługiwanej technologii i dostępnych biuletynów.