CVE-2026-63003

## 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 permi