CVE-2026-63003 — django-cms

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 the source widget is hidden, so the queryset is never narrowed to the user’s site/subtree.
• cms/admin/forms.py — AddPageForm.clean() validates only URL uniqueness; source is never validated against the user.
• cms/admin/pageadmin.py — duplicate() seeds source from the URL only on GET; on POST the value comes entirely from the request body.
• cms/admin/forms.py — AddPageForm.save() → from_source() performs source.copy(..., permissions=False) and copies every placeholder and all plugins of source into a new page on the attacker’s site. Because permissions=False drops 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

1. Log in as a staff user attacker who has add page permission but no view/change permission on a target (secret / other-site) page SECRET_ID.
2. Send (the URL <id> only needs to be a PageContent the 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>

1. 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