django-cms

Summary

The django-cms frontend-editing structure endpoint

GET /<lang>/admin/cms/placeholder/object/<content_type_id>/structure/<object_id>/

did not perform an object-level authorization check for non-PageContent objects. Any authenticated, active staff user could request the structure endpoint for a frontend-editable object (a model using PlaceholderRelationField) and read its placeholder/plugin structure, even without permission to change that object and without the cms.use_structure permission that the toolbar UI requires before offering structure mode.

PageContent objects were already protected (a page-view check added in GHSA/PR #8644); this advisory covers the remaining non-PageContent branch of the same view.

Severity

The issue is staff-gated and read-only, disclosing CMS structure metadata (placeholder slot names, plugin tree, plugin identifiers/labels, object existence) rather than write access or arbitrary field data.

Affected versions

• django-cms >= 4.0.0, <= 5.0.x and 5.1.0a1 (the vulnerable non-PageContent branch was introduced with the frontend-editing endpoints in 4.0)

Patched versions

• django-cms TODO: 5.0.9

Preconditions

• An authenticated, active staff account (is_staff=True).
• The deployment exposes a non-PageContent model with django-cms placeholders / frontend editing (e.g. via PlaceholderRelationField).
• The attacker can guess or enumerate the target content_type_id and object id.
• The attacker needs no model/object change permission and no cms.use_structure permission.

Impact

A low-privileged staff user can read the editorial placeholder/plugin structure of non-PageContent objects they are not authorized to edit through the toolbar. Depending on the installed plugins and templates this may reveal placeholder names, plugin layout, plugin identifiers and the existence of objects owned by other staff users or teams. This is most relevant for deployments using third-party or custom django-cms apps that expose frontend-editable objects outside the page tree.

Proof of concept

Using django-cms' own test model placeholder_relation_field_app.FancyPoll (a non-PageContent model with a PlaceholderRelationField):

target = FancyPoll.objects.create(name="private-fancy-poll")
placeholder = rescan_placeholders_for_obj(target)["content"]
attacker = self._create_user("low_staff", is_staff=True, is_superuser=False)
# attacker has neither change_fancypoll nor cms.use_structure

with self.login_user_context(attacker):
    response = self.client.get(get_object_structure_url(target, language="en"))

# Before fix: HTTP 200, body contains '"placeholder_id": "<pk>"'
# After fix:  HTTP 404, structure not disclosed

Patch

render_object_structure now authorizes the non-PageContent branch, mirroring Placeholder.has_change_permission at the object level (honouring a custom has_placeholder_change_permission hook, otherwise falling back to the model/object change permission) and returning 404 when the user is not authorized:

else:
    content_type_obj = content_type.get_object_for_this_type(pk=object_id)
    if not _can_change_placeholder_object(request.user, content_type_obj):
        raise Http404

Workarounds

No configuration workaround. Deployments that do not register any non-PageContent frontend-editable model are not affected. Otherwise, upgrade to a patched release.

Credit

Reported by doanmanhducz.

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>

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

Summary

When plugin rendering fails in edit mode, django CMS renders a cms-rendering-exception block so editors can see that a placeholder could not be rendered. Older code built that block's heading by interpolating the exception message, placeholder/source strings, and the failing plugin's short description directly into an HTML string, then returned the placeholder output as safe markup.

If an editor could store HTML in data used by a plugin's get_short_description() (or in other values interpolated into the exception message), and that plugin later raised during edit-mode rendering, the payload was parsed as HTML in the staff user's browser. This is a stored XSS condition in the CMS editing context.

Impact

The vulnerable path is only reached when placeholder rendering catches a plugin rendering exception:

try:
    placeholder_content = "".join(plugin_content)
except Exception as e:
    context["exc_info"] = sys.exc_info()
    placeholder_content = self.render_exception("rendering placeholder", context, placeholder, editable)

render_exception() constructs a message from values that can include stored content:

• value - the exception message.
• placeholder - the placeholder string representation.
• placeholder.source - the source object string representation, such as page content.
• instance.get_short_description() - plugin-provided summary text, often derived from plugin model fields.

In the vulnerable implementation, that message was embedded directly into an HTML heading. The final placeholder content was later returned through mark_safe, so Django template autoescaping did not protect the heading.

settings.DEBUG does not mitigate the issue: it only controls whether Django's traceback HTML is appended. The custom heading is rendered in edit mode regardless of DEBUG.

Patch

Escape the custom exception heading before returning it as safe placeholder markup. The current fixed code uses format_html, which escapes message before inserting it into the heading:

heading = format_html('<h2 class="cms-rendering-exception-title">{}</h2>', message)

The traceback HTML from ExceptionReporter.get_traceback_html() should remain separate from django CMS's custom heading; Django's traceback escaping does not protect additional HTML assembled by django CMS.

Workarounds

Until patched, reduce exposure by ensuring only fully trusted staff can edit plugins whose stored fields are included in get_short_description(), and fix or disable plugins that can be made to raise during edit-mode rendering. This is only a partial mitigation because the escaping bug is in the shared exception-rendering path.

References

• cms/plugin_rendering.py - ContentRenderer.render_placeholder
• cms/plugin_rendering.py - ContentRenderer.render_exception
• Fixed code: heading = format_html('<h2 class="cms-rendering-exception-title">{}</h2>', message)
• Regression tests: cms.tests.test_plugin_renderers.TestExceptionCatchers.test_exception_in_plugin_render_escapes_user_content_in_edit_mode, cms.tests.test_plugin_renderers.TestLegacyRendererExceptionCatcher.test_exception_in_plugin_render_escapes_user_content_in_edit_mode

Summary

The CMS page cache key ignores the request headers that plugins declare via get_vary_cache_on(). The header is added to the response Vary header, but the CMS's own cache key does not incorporate the header values, so the first visitor's variant is served to all subsequent visitors regardless of their header values.

Details

_page_cache_key (in cms/cache/page.py) keys only on cache prefix, site, language, path and timezone. set_page_cache collects the plugin-declared vary headers and calls patch_vary_headers(response, ...) (affecting only the emitted Vary header), but stores and retrieves the cached page under the header-agnostic key. get_page_cache therefore returns whichever variant was cached first.

Impact

• Information disclosure: when a plugin varies its output on a request header (e.g. Country-Code), the variant rendered for the first anonymous visitor is served to everyone until the entry expires, leaking request-specific content across users.
• Cache poisoning: an unauthenticated attacker can prime the anonymous page cache with content rendered from attacker-chosen header values, which is then served to subsequent visitors.

Applies only when CMS_PAGE_CACHE is enabled and at least one plugin implements get_vary_cache_on().

Patches

Fixed in 5.0.8: the page cache now folds the request's values implements get_vary_cache_on().

Patches

Fixed in 5.0.8: the page cache now folds the request's values for plugin-declared vary headers into the content key. The set of vary headers is persisted on write and looked up first on read (mirroring Django's learn_cache_key/get_cache_key); a missing header-list entry degrades to a cache miss, never a wrong-variant hit.

Workarounds

Disable CMS_PAGE_CACHE, or avoid plugins that rely on get_vary_cache_on(), until upgraded.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The move_plugin admin endpoint does not prevent a plugin from being reparented under itself or one of its own descendants. Doing so creates a cycle in the plugin tree, after which the recursive descendant/ancestor SQL queries loop without terminating, stalling the request worker.

Details

move_plugin (in cms/admin/placeholderadmin.py) accepts a plugin_parent POST parameter and, for an in-placeholder move, sets the plugin's parent to the target without any cycle/ancestor check. If the target parent is a descendant of the moved plugin, the resulting parent_id graph contains a cycle.

Descendant and ancestor traversal is implemented with WITH RECURSIVE CTEs (_get_descendants_cte / _get_ancestors_cte in cms/models/pluginmodel.py) that have no cycle clause or depth limit. On a cyclic tree these recurse indefinitely (PostgreSQL/SQLite) or error at the recursion limit (MySQL). get_descendants() is invoked while building the move response and on subsequent operations on the affected subtree.

Impact

An authenticated staff user with permission to change plugins in at least one placeholder can corrupt that placeholder's plugin tree, causing requests that traverse it (rendering, copy, delete) to hang and consume application workers (denial of service). The tree is also left in a corrupted state.

Requires CMS_PERMISSION/plugin-change permission on a placeholder.

Patches

Fixed in 5.0.8: move_plugin now rejects (HTTP 400) any move that would place a plugin inside itself or one of its descendants, before any tree mutation or traversal.

Workarounds

None. Upgrade is recommended.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The django-cms frontend-editing structure endpoint

GET /<lang>/admin/cms/placeholder/object/<content_type_id>/structure/<object_id>/

did not perform an object-level authorization check for non-PageContent objects. Any authenticated, active staff user could request the structure endpoint for a frontend-editable object (a model using PlaceholderRelationField) and read its placeholder/plugin structure, even without permission to change that object and without the cms.use_structure permission that the toolbar UI requires before offering structure mode.

PageContent objects were already protected (a page-view check added in GHSA/PR #8644); this advisory covers the remaining non-PageContent branch of the same view.

Severity

The issue is staff-gated and read-only, disclosing CMS structure metadata (placeholder slot names, plugin tree, plugin identifiers/labels, object existence) rather than write access or arbitrary field data.

Affected versions

• django-cms >= 4.0.0, <= 5.0.x and 5.1.0a1 (the vulnerable non-PageContent branch was introduced with the frontend-editing endpoints in 4.0)

Patched versions

• django-cms TODO: 5.0.9

Preconditions

• An authenticated, active staff account (is_staff=True).
• The deployment exposes a non-PageContent model with django-cms placeholders / frontend editing (e.g. via PlaceholderRelationField).
• The attacker can guess or enumerate the target content_type_id and object id.
• The attacker needs no model/object change permission and no cms.use_structure permission.

Impact

A low-privileged staff user can read the editorial placeholder/plugin structure of non-PageContent objects they are not authorized to edit through the toolbar. Depending on the installed plugins and templates this may reveal placeholder names, plugin layout, plugin identifiers and the existence of objects owned by other staff users or teams. This is most relevant for deployments using third-party or custom django-cms apps that expose frontend-editable objects outside the page tree.

Proof of concept

Using django-cms' own test model placeholder_relation_field_app.FancyPoll (a non-PageContent model with a PlaceholderRelationField):

target = FancyPoll.objects.create(name="private-fancy-poll")
placeholder = rescan_placeholders_for_obj(target)["content"]
attacker = self._create_user("low_staff", is_staff=True, is_superuser=False)
# attacker has neither change_fancypoll nor cms.use_structure

with self.login_user_context(attacker):
    response = self.client.get(get_object_structure_url(target, language="en"))

# Before fix: HTTP 200, body contains '"placeholder_id": "<pk>"'
# After fix:  HTTP 404, structure not disclosed

Patch

render_object_structure now authorizes the non-PageContent branch, mirroring Placeholder.has_change_permission at the object level (honouring a custom has_placeholder_change_permission hook, otherwise falling back to the model/object change permission) and returning 404 when the user is not authorized:

else:
    content_type_obj = content_type.get_object_for_this_type(pk=object_id)
    if not _can_change_placeholder_object(request.user, content_type_obj):
        raise Http404

Workarounds

No configuration workaround. Deployments that do not register any non-PageContent frontend-editable model are not affected. Otherwise, upgrade to a patched release.

Credit

Reported by doanmanhducz.

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>

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

Summary

The structure-board endpoint (render_object_structure) renders a page's plugin structure without verifying that the requesting user is allowed to view the page. The edit and preview endpoints enforce this via render_page(), but the structure endpoint does not, allowing a low-privileged staff user to read the plugin structure of a view-restricted page.

Details

render_object_structure (in cms/views.py) loads the PageContent object and renders cms/toolbar/structure.html directly. Unlike render_object_endpoint (used by edit/preview), which renders through render_pagecontent → render_page and calls user_can_view_page(request.user, page) (returning 404 when the user may not view the page), the structure endpoint performs no page-level authorization.

The rendered structure board includes each plugin's get_short_description() (e.g. link names/URLs, text snippets), so the content of a restricted page is disclosed, not just its shape.

Impact

A staff user (any account with is_staff=True) who lacks view permission on a view-restricted page can retrieve that page's plugin structure and short descriptions by requesting the structure endpoint with the page's content-type id and object id.

This only applies when CMS_PERMISSION=True and the page has view restrictions (or CMS_PUBLIC_FOR='staff'). Sites without per-page view restrictions are not affected.

Patches

Fixed in 5.0.8: the structure endpoint now enforces user_can_view_page() for PageContent objects, matching edit/preview.

Workarounds

None other than restricting staff access. Upgrade is recommended.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The clipboard copy paths of the copy_plugins admin endpoint validate only the target (the user's own clipboard) and skip source-side authorization. A staff user can copy plugins out of a placeholder they have no permission on into their clipboard, then read the (secret) content.

Details

In cms/admin/placeholderadmin.py, _copy_plugin_to_clipboard and _copy_placeholder_to_clipboard check has_copy_plugins_permission, which only evaluates request.toolbar.clipboard.has_add_plugins_permission(...) — the clipboard belongs to the requesting user, and check_source is likewise applied only to the clipboard. The source placeholder identified by the attacker-supplied source_placeholder_id / source_plugin_id is never authorization-checked. (The placeholder-to-placeholder copy path, has_copy_from_placeholder_permission, correctly checks both sides.)

Impact

A staff user holding the global add permission for a plugin type, but with no access to a given placeholder/page, can copy that placeholder's plugins into their own clipboard and read content (e.g. link names/URLs, text) they cannot reach through the normal edit endpoints.

Requires CMS_PERMISSION=True with per-placeholder/page restrictions.

Patches

Fixed in 5.0.8: the clipboard copy paths now also verify source-side permission (has_add_plugins_permission + check_source on the source placeholder), matching placeholder-to-placeholder copy.

Workarounds

None. Upgrade is recommended.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The CMS page cache key ignores the request headers that plugins declare via get_vary_cache_on(). The header is added to the response Vary header, but the CMS's own cache key does not incorporate the header values, so the first visitor's variant is served to all subsequent visitors regardless of their header values.

Details

_page_cache_key (in cms/cache/page.py) keys only on cache prefix, site, language, path and timezone. set_page_cache collects the plugin-declared vary headers and calls patch_vary_headers(response, ...) (affecting only the emitted Vary header), but stores and retrieves the cached page under the header-agnostic key. get_page_cache therefore returns whichever variant was cached first.

Impact

• Information disclosure: when a plugin varies its output on a request header (e.g. Country-Code), the variant rendered for the first anonymous visitor is served to everyone until the entry expires, leaking request-specific content across users.
• Cache poisoning: an unauthenticated attacker can prime the anonymous page cache with content rendered from attacker-chosen header values, which is then served to subsequent visitors.

Applies only when CMS_PAGE_CACHE is enabled and at least one plugin implements get_vary_cache_on().

Patches

Fixed in 5.0.8: the page cache now folds the request's values implements get_vary_cache_on().

Patches

Fixed in 5.0.8: the page cache now folds the request's values for plugin-declared vary headers into the content key. The set of vary headers is persisted on write and looked up first on read (mirroring Django's learn_cache_key/get_cache_key); a missing header-list entry degrades to a cache miss, never a wrong-variant hit.

Workarounds

Disable CMS_PAGE_CACHE, or avoid plugins that rely on get_vary_cache_on(), until upgraded.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The move_plugin admin endpoint does not prevent a plugin from being reparented under itself or one of its own descendants. Doing so creates a cycle in the plugin tree, after which the recursive descendant/ancestor SQL queries loop without terminating, stalling the request worker.

Details

move_plugin (in cms/admin/placeholderadmin.py) accepts a plugin_parent POST parameter and, for an in-placeholder move, sets the plugin's parent to the target without any cycle/ancestor check. If the target parent is a descendant of the moved plugin, the resulting parent_id graph contains a cycle.

Descendant and ancestor traversal is implemented with WITH RECURSIVE CTEs (_get_descendants_cte / _get_ancestors_cte in cms/models/pluginmodel.py) that have no cycle clause or depth limit. On a cyclic tree these recurse indefinitely (PostgreSQL/SQLite) or error at the recursion limit (MySQL). get_descendants() is invoked while building the move response and on subsequent operations on the affected subtree.

Impact

An authenticated staff user with permission to change plugins in at least one placeholder can corrupt that placeholder's plugin tree, causing requests that traverse it (rendering, copy, delete) to hang and consume application workers (denial of service). The tree is also left in a corrupted state.

Requires CMS_PERMISSION/plugin-change permission on a placeholder.

Patches

Fixed in 5.0.8: move_plugin now rejects (HTTP 400) any move that would place a plugin inside itself or one of its descendants, before any tree mutation or traversal.

Workarounds

None. Upgrade is recommended.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The django-cms frontend-editing structure endpoint

GET /<lang>/admin/cms/placeholder/object/<content_type_id>/structure/<object_id>/

did not perform an object-level authorization check for non-PageContent objects. Any authenticated, active staff user could request the structure endpoint for a frontend-editable object (a model using PlaceholderRelationField) and read its placeholder/plugin structure, even without permission to change that object and without the cms.use_structure permission that the toolbar UI requires before offering structure mode.

PageContent objects were already protected (a page-view check added in GHSA/PR #8644); this advisory covers the remaining non-PageContent branch of the same view.

Severity

The issue is staff-gated and read-only, disclosing CMS structure metadata (placeholder slot names, plugin tree, plugin identifiers/labels, object existence) rather than write access or arbitrary field data.

Affected versions

• django-cms >= 4.0.0, <= 5.0.x and 5.1.0a1 (the vulnerable non-PageContent branch was introduced with the frontend-editing endpoints in 4.0)

Patched versions

• django-cms TODO: 5.0.9

Preconditions

• An authenticated, active staff account (is_staff=True).
• The deployment exposes a non-PageContent model with django-cms placeholders / frontend editing (e.g. via PlaceholderRelationField).
• The attacker can guess or enumerate the target content_type_id and object id.
• The attacker needs no model/object change permission and no cms.use_structure permission.

Impact

A low-privileged staff user can read the editorial placeholder/plugin structure of non-PageContent objects they are not authorized to edit through the toolbar. Depending on the installed plugins and templates this may reveal placeholder names, plugin layout, plugin identifiers and the existence of objects owned by other staff users or teams. This is most relevant for deployments using third-party or custom django-cms apps that expose frontend-editable objects outside the page tree.

Proof of concept

Using django-cms' own test model placeholder_relation_field_app.FancyPoll (a non-PageContent model with a PlaceholderRelationField):

target = FancyPoll.objects.create(name="private-fancy-poll")
placeholder = rescan_placeholders_for_obj(target)["content"]
attacker = self._create_user("low_staff", is_staff=True, is_superuser=False)
# attacker has neither change_fancypoll nor cms.use_structure

with self.login_user_context(attacker):
    response = self.client.get(get_object_structure_url(target, language="en"))

# Before fix: HTTP 200, body contains '"placeholder_id": "<pk>"'
# After fix:  HTTP 404, structure not disclosed

Patch

render_object_structure now authorizes the non-PageContent branch, mirroring Placeholder.has_change_permission at the object level (honouring a custom has_placeholder_change_permission hook, otherwise falling back to the model/object change permission) and returning 404 when the user is not authorized:

else:
    content_type_obj = content_type.get_object_for_this_type(pk=object_id)
    if not _can_change_placeholder_object(request.user, content_type_obj):
        raise Http404

Workarounds

No configuration workaround. Deployments that do not register any non-PageContent frontend-editable model are not affected. Otherwise, upgrade to a patched release.

Credit

Reported by doanmanhducz.

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>

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

Summary

The structure-board endpoint (render_object_structure) renders a page's plugin structure without verifying that the requesting user is allowed to view the page. The edit and preview endpoints enforce this via render_page(), but the structure endpoint does not, allowing a low-privileged staff user to read the plugin structure of a view-restricted page.

Details

render_object_structure (in cms/views.py) loads the PageContent object and renders cms/toolbar/structure.html directly. Unlike render_object_endpoint (used by edit/preview), which renders through render_pagecontent → render_page and calls user_can_view_page(request.user, page) (returning 404 when the user may not view the page), the structure endpoint performs no page-level authorization.

The rendered structure board includes each plugin's get_short_description() (e.g. link names/URLs, text snippets), so the content of a restricted page is disclosed, not just its shape.

Impact

A staff user (any account with is_staff=True) who lacks view permission on a view-restricted page can retrieve that page's plugin structure and short descriptions by requesting the structure endpoint with the page's content-type id and object id.

This only applies when CMS_PERMISSION=True and the page has view restrictions (or CMS_PUBLIC_FOR='staff'). Sites without per-page view restrictions are not affected.

Patches

Fixed in 5.0.8: the structure endpoint now enforces user_can_view_page() for PageContent objects, matching edit/preview.

Workarounds

None other than restricting staff access. Upgrade is recommended.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The clipboard copy paths of the copy_plugins admin endpoint validate only the target (the user's own clipboard) and skip source-side authorization. A staff user can copy plugins out of a placeholder they have no permission on into their clipboard, then read the (secret) content.

Details

In cms/admin/placeholderadmin.py, _copy_plugin_to_clipboard and _copy_placeholder_to_clipboard check has_copy_plugins_permission, which only evaluates request.toolbar.clipboard.has_add_plugins_permission(...) — the clipboard belongs to the requesting user, and check_source is likewise applied only to the clipboard. The source placeholder identified by the attacker-supplied source_placeholder_id / source_plugin_id is never authorization-checked. (The placeholder-to-placeholder copy path, has_copy_from_placeholder_permission, correctly checks both sides.)

Impact

A staff user holding the global add permission for a plugin type, but with no access to a given placeholder/page, can copy that placeholder's plugins into their own clipboard and read content (e.g. link names/URLs, text) they cannot reach through the normal edit endpoints.

Requires CMS_PERMISSION=True with per-placeholder/page restrictions.

Patches

Fixed in 5.0.8: the clipboard copy paths now also verify source-side permission (has_add_plugins_permission + check_source on the source placeholder), matching placeholder-to-placeholder copy.

Workarounds

None. Upgrade is recommended.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The CMS page cache key ignores the request headers that plugins declare via get_vary_cache_on(). The header is added to the response Vary header, but the CMS's own cache key does not incorporate the header values, so the first visitor's variant is served to all subsequent visitors regardless of their header values.

Details

_page_cache_key (in cms/cache/page.py) keys only on cache prefix, site, language, path and timezone. set_page_cache collects the plugin-declared vary headers and calls patch_vary_headers(response, ...) (affecting only the emitted Vary header), but stores and retrieves the cached page under the header-agnostic key. get_page_cache therefore returns whichever variant was cached first.

Impact

• Information disclosure: when a plugin varies its output on a request header (e.g. Country-Code), the variant rendered for the first anonymous visitor is served to everyone until the entry expires, leaking request-specific content across users.
• Cache poisoning: an unauthenticated attacker can prime the anonymous page cache with content rendered from attacker-chosen header values, which is then served to subsequent visitors.

Applies only when CMS_PAGE_CACHE is enabled and at least one plugin implements get_vary_cache_on().

Patches

Fixed in 5.0.8: the page cache now folds the request's values implements get_vary_cache_on().

Patches

Fixed in 5.0.8: the page cache now folds the request's values for plugin-declared vary headers into the content key. The set of vary headers is persisted on write and looked up first on read (mirroring Django's learn_cache_key/get_cache_key); a missing header-list entry degrades to a cache miss, never a wrong-variant hit.

Workarounds

Disable CMS_PAGE_CACHE, or avoid plugins that rely on get_vary_cache_on(), until upgraded.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The move_plugin admin endpoint does not prevent a plugin from being reparented under itself or one of its own descendants. Doing so creates a cycle in the plugin tree, after which the recursive descendant/ancestor SQL queries loop without terminating, stalling the request worker.

Details

move_plugin (in cms/admin/placeholderadmin.py) accepts a plugin_parent POST parameter and, for an in-placeholder move, sets the plugin's parent to the target without any cycle/ancestor check. If the target parent is a descendant of the moved plugin, the resulting parent_id graph contains a cycle.

Descendant and ancestor traversal is implemented with WITH RECURSIVE CTEs (_get_descendants_cte / _get_ancestors_cte in cms/models/pluginmodel.py) that have no cycle clause or depth limit. On a cyclic tree these recurse indefinitely (PostgreSQL/SQLite) or error at the recursion limit (MySQL). get_descendants() is invoked while building the move response and on subsequent operations on the affected subtree.

Impact

An authenticated staff user with permission to change plugins in at least one placeholder can corrupt that placeholder's plugin tree, causing requests that traverse it (rendering, copy, delete) to hang and consume application workers (denial of service). The tree is also left in a corrupted state.

Requires CMS_PERMISSION/plugin-change permission on a placeholder.

Patches

Fixed in 5.0.8: move_plugin now rejects (HTTP 400) any move that would place a plugin inside itself or one of its descendants, before any tree mutation or traversal.

Workarounds

None. Upgrade is recommended.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The django-cms frontend-editing structure endpoint

GET /<lang>/admin/cms/placeholder/object/<content_type_id>/structure/<object_id>/

did not perform an object-level authorization check for non-PageContent objects. Any authenticated, active staff user could request the structure endpoint for a frontend-editable object (a model using PlaceholderRelationField) and read its placeholder/plugin structure, even without permission to change that object and without the cms.use_structure permission that the toolbar UI requires before offering structure mode.

PageContent objects were already protected (a page-view check added in GHSA/PR #8644); this advisory covers the remaining non-PageContent branch of the same view.

Severity

The issue is staff-gated and read-only, disclosing CMS structure metadata (placeholder slot names, plugin tree, plugin identifiers/labels, object existence) rather than write access or arbitrary field data.

Affected versions

• django-cms >= 4.0.0, <= 5.0.x and 5.1.0a1 (the vulnerable non-PageContent branch was introduced with the frontend-editing endpoints in 4.0)

Patched versions

• django-cms TODO: 5.0.9

Preconditions

• An authenticated, active staff account (is_staff=True).
• The deployment exposes a non-PageContent model with django-cms placeholders / frontend editing (e.g. via PlaceholderRelationField).
• The attacker can guess or enumerate the target content_type_id and object id.
• The attacker needs no model/object change permission and no cms.use_structure permission.

Impact

A low-privileged staff user can read the editorial placeholder/plugin structure of non-PageContent objects they are not authorized to edit through the toolbar. Depending on the installed plugins and templates this may reveal placeholder names, plugin layout, plugin identifiers and the existence of objects owned by other staff users or teams. This is most relevant for deployments using third-party or custom django-cms apps that expose frontend-editable objects outside the page tree.

Proof of concept

Using django-cms' own test model placeholder_relation_field_app.FancyPoll (a non-PageContent model with a PlaceholderRelationField):

target = FancyPoll.objects.create(name="private-fancy-poll")
placeholder = rescan_placeholders_for_obj(target)["content"]
attacker = self._create_user("low_staff", is_staff=True, is_superuser=False)
# attacker has neither change_fancypoll nor cms.use_structure

with self.login_user_context(attacker):
    response = self.client.get(get_object_structure_url(target, language="en"))

# Before fix: HTTP 200, body contains '"placeholder_id": "<pk>"'
# After fix:  HTTP 404, structure not disclosed

Patch

render_object_structure now authorizes the non-PageContent branch, mirroring Placeholder.has_change_permission at the object level (honouring a custom has_placeholder_change_permission hook, otherwise falling back to the model/object change permission) and returning 404 when the user is not authorized:

else:
    content_type_obj = content_type.get_object_for_this_type(pk=object_id)
    if not _can_change_placeholder_object(request.user, content_type_obj):
        raise Http404

Workarounds

No configuration workaround. Deployments that do not register any non-PageContent frontend-editable model are not affected. Otherwise, upgrade to a patched release.

Credit

Reported by doanmanhducz.

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>

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

Summary

The structure-board endpoint (render_object_structure) renders a page's plugin structure without verifying that the requesting user is allowed to view the page. The edit and preview endpoints enforce this via render_page(), but the structure endpoint does not, allowing a low-privileged staff user to read the plugin structure of a view-restricted page.

Details

render_object_structure (in cms/views.py) loads the PageContent object and renders cms/toolbar/structure.html directly. Unlike render_object_endpoint (used by edit/preview), which renders through render_pagecontent → render_page and calls user_can_view_page(request.user, page) (returning 404 when the user may not view the page), the structure endpoint performs no page-level authorization.

The rendered structure board includes each plugin's get_short_description() (e.g. link names/URLs, text snippets), so the content of a restricted page is disclosed, not just its shape.

Impact

A staff user (any account with is_staff=True) who lacks view permission on a view-restricted page can retrieve that page's plugin structure and short descriptions by requesting the structure endpoint with the page's content-type id and object id.

This only applies when CMS_PERMISSION=True and the page has view restrictions (or CMS_PUBLIC_FOR='staff'). Sites without per-page view restrictions are not affected.

Patches

Fixed in 5.0.8: the structure endpoint now enforces user_can_view_page() for PageContent objects, matching edit/preview.

Workarounds

None other than restricting staff access. Upgrade is recommended.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The clipboard copy paths of the copy_plugins admin endpoint validate only the target (the user's own clipboard) and skip source-side authorization. A staff user can copy plugins out of a placeholder they have no permission on into their clipboard, then read the (secret) content.

Details

In cms/admin/placeholderadmin.py, _copy_plugin_to_clipboard and _copy_placeholder_to_clipboard check has_copy_plugins_permission, which only evaluates request.toolbar.clipboard.has_add_plugins_permission(...) — the clipboard belongs to the requesting user, and check_source is likewise applied only to the clipboard. The source placeholder identified by the attacker-supplied source_placeholder_id / source_plugin_id is never authorization-checked. (The placeholder-to-placeholder copy path, has_copy_from_placeholder_permission, correctly checks both sides.)

Impact

A staff user holding the global add permission for a plugin type, but with no access to a given placeholder/page, can copy that placeholder's plugins into their own clipboard and read content (e.g. link names/URLs, text) they cannot reach through the normal edit endpoints.

Requires CMS_PERMISSION=True with per-placeholder/page restrictions.

Patches

Fixed in 5.0.8: the clipboard copy paths now also verify source-side permission (has_add_plugins_permission + check_source on the source placeholder), matching placeholder-to-placeholder copy.

Workarounds

None. Upgrade is recommended.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The CMS page cache key ignores the request headers that plugins declare via get_vary_cache_on(). The header is added to the response Vary header, but the CMS's own cache key does not incorporate the header values, so the first visitor's variant is served to all subsequent visitors regardless of their header values.

Details

_page_cache_key (in cms/cache/page.py) keys only on cache prefix, site, language, path and timezone. set_page_cache collects the plugin-declared vary headers and calls patch_vary_headers(response, ...) (affecting only the emitted Vary header), but stores and retrieves the cached page under the header-agnostic key. get_page_cache therefore returns whichever variant was cached first.

Impact

• Information disclosure: when a plugin varies its output on a request header (e.g. Country-Code), the variant rendered for the first anonymous visitor is served to everyone until the entry expires, leaking request-specific content across users.
• Cache poisoning: an unauthenticated attacker can prime the anonymous page cache with content rendered from attacker-chosen header values, which is then served to subsequent visitors.

Applies only when CMS_PAGE_CACHE is enabled and at least one plugin implements get_vary_cache_on().

Patches

Fixed in 5.0.8: the page cache now folds the request's values implements get_vary_cache_on().

Patches

Fixed in 5.0.8: the page cache now folds the request's values for plugin-declared vary headers into the content key. The set of vary headers is persisted on write and looked up first on read (mirroring Django's learn_cache_key/get_cache_key); a missing header-list entry degrades to a cache miss, never a wrong-variant hit.

Workarounds

Disable CMS_PAGE_CACHE, or avoid plugins that rely on get_vary_cache_on(), until upgraded.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The move_plugin admin endpoint does not prevent a plugin from being reparented under itself or one of its own descendants. Doing so creates a cycle in the plugin tree, after which the recursive descendant/ancestor SQL queries loop without terminating, stalling the request worker.

Details

move_plugin (in cms/admin/placeholderadmin.py) accepts a plugin_parent POST parameter and, for an in-placeholder move, sets the plugin's parent to the target without any cycle/ancestor check. If the target parent is a descendant of the moved plugin, the resulting parent_id graph contains a cycle.

Descendant and ancestor traversal is implemented with WITH RECURSIVE CTEs (_get_descendants_cte / _get_ancestors_cte in cms/models/pluginmodel.py) that have no cycle clause or depth limit. On a cyclic tree these recurse indefinitely (PostgreSQL/SQLite) or error at the recursion limit (MySQL). get_descendants() is invoked while building the move response and on subsequent operations on the affected subtree.

Impact

An authenticated staff user with permission to change plugins in at least one placeholder can corrupt that placeholder's plugin tree, causing requests that traverse it (rendering, copy, delete) to hang and consume application workers (denial of service). The tree is also left in a corrupted state.

Requires CMS_PERMISSION/plugin-change permission on a placeholder.

Patches

Fixed in 5.0.8: move_plugin now rejects (HTTP 400) any move that would place a plugin inside itself or one of its descendants, before any tree mutation or traversal.

Workarounds

None. Upgrade is recommended.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The django-cms frontend-editing structure endpoint

GET /<lang>/admin/cms/placeholder/object/<content_type_id>/structure/<object_id>/

did not perform an object-level authorization check for non-PageContent objects. Any authenticated, active staff user could request the structure endpoint for a frontend-editable object (a model using PlaceholderRelationField) and read its placeholder/plugin structure, even without permission to change that object and without the cms.use_structure permission that the toolbar UI requires before offering structure mode.

PageContent objects were already protected (a page-view check added in GHSA/PR #8644); this advisory covers the remaining non-PageContent branch of the same view.

Severity

The issue is staff-gated and read-only, disclosing CMS structure metadata (placeholder slot names, plugin tree, plugin identifiers/labels, object existence) rather than write access or arbitrary field data.

Affected versions

• django-cms >= 4.0.0, <= 5.0.x and 5.1.0a1 (the vulnerable non-PageContent branch was introduced with the frontend-editing endpoints in 4.0)

Patched versions

• django-cms TODO: 5.0.9

Preconditions

• An authenticated, active staff account (is_staff=True).
• The deployment exposes a non-PageContent model with django-cms placeholders / frontend editing (e.g. via PlaceholderRelationField).
• The attacker can guess or enumerate the target content_type_id and object id.
• The attacker needs no model/object change permission and no cms.use_structure permission.

Impact

A low-privileged staff user can read the editorial placeholder/plugin structure of non-PageContent objects they are not authorized to edit through the toolbar. Depending on the installed plugins and templates this may reveal placeholder names, plugin layout, plugin identifiers and the existence of objects owned by other staff users or teams. This is most relevant for deployments using third-party or custom django-cms apps that expose frontend-editable objects outside the page tree.

Proof of concept

Using django-cms' own test model placeholder_relation_field_app.FancyPoll (a non-PageContent model with a PlaceholderRelationField):

target = FancyPoll.objects.create(name="private-fancy-poll")
placeholder = rescan_placeholders_for_obj(target)["content"]
attacker = self._create_user("low_staff", is_staff=True, is_superuser=False)
# attacker has neither change_fancypoll nor cms.use_structure

with self.login_user_context(attacker):
    response = self.client.get(get_object_structure_url(target, language="en"))

# Before fix: HTTP 200, body contains '"placeholder_id": "<pk>"'
# After fix:  HTTP 404, structure not disclosed

Patch

render_object_structure now authorizes the non-PageContent branch, mirroring Placeholder.has_change_permission at the object level (honouring a custom has_placeholder_change_permission hook, otherwise falling back to the model/object change permission) and returning 404 when the user is not authorized:

else:
    content_type_obj = content_type.get_object_for_this_type(pk=object_id)
    if not _can_change_placeholder_object(request.user, content_type_obj):
        raise Http404

Workarounds

No configuration workaround. Deployments that do not register any non-PageContent frontend-editable model are not affected. Otherwise, upgrade to a patched release.

Credit

Reported by doanmanhducz.

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>

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

Summary

The structure-board endpoint (render_object_structure) renders a page's plugin structure without verifying that the requesting user is allowed to view the page. The edit and preview endpoints enforce this via render_page(), but the structure endpoint does not, allowing a low-privileged staff user to read the plugin structure of a view-restricted page.

Details

render_object_structure (in cms/views.py) loads the PageContent object and renders cms/toolbar/structure.html directly. Unlike render_object_endpoint (used by edit/preview), which renders through render_pagecontent → render_page and calls user_can_view_page(request.user, page) (returning 404 when the user may not view the page), the structure endpoint performs no page-level authorization.

The rendered structure board includes each plugin's get_short_description() (e.g. link names/URLs, text snippets), so the content of a restricted page is disclosed, not just its shape.

Impact

A staff user (any account with is_staff=True) who lacks view permission on a view-restricted page can retrieve that page's plugin structure and short descriptions by requesting the structure endpoint with the page's content-type id and object id.

This only applies when CMS_PERMISSION=True and the page has view restrictions (or CMS_PUBLIC_FOR='staff'). Sites without per-page view restrictions are not affected.

Patches

Fixed in 5.0.8: the structure endpoint now enforces user_can_view_page() for PageContent objects, matching edit/preview.

Workarounds

None other than restricting staff access. Upgrade is recommended.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The clipboard copy paths of the copy_plugins admin endpoint validate only the target (the user's own clipboard) and skip source-side authorization. A staff user can copy plugins out of a placeholder they have no permission on into their clipboard, then read the (secret) content.

Details

In cms/admin/placeholderadmin.py, _copy_plugin_to_clipboard and _copy_placeholder_to_clipboard check has_copy_plugins_permission, which only evaluates request.toolbar.clipboard.has_add_plugins_permission(...) — the clipboard belongs to the requesting user, and check_source is likewise applied only to the clipboard. The source placeholder identified by the attacker-supplied source_placeholder_id / source_plugin_id is never authorization-checked. (The placeholder-to-placeholder copy path, has_copy_from_placeholder_permission, correctly checks both sides.)

Impact

A staff user holding the global add permission for a plugin type, but with no access to a given placeholder/page, can copy that placeholder's plugins into their own clipboard and read content (e.g. link names/URLs, text) they cannot reach through the normal edit endpoints.

Requires CMS_PERMISSION=True with per-placeholder/page restrictions.

Patches

Fixed in 5.0.8: the clipboard copy paths now also verify source-side permission (has_add_plugins_permission + check_source on the source placeholder), matching placeholder-to-placeholder copy.

Workarounds

None. Upgrade is recommended.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The CMS page cache key ignores the request headers that plugins declare via get_vary_cache_on(). The header is added to the response Vary header, but the CMS's own cache key does not incorporate the header values, so the first visitor's variant is served to all subsequent visitors regardless of their header values.

Details

_page_cache_key (in cms/cache/page.py) keys only on cache prefix, site, language, path and timezone. set_page_cache collects the plugin-declared vary headers and calls patch_vary_headers(response, ...) (affecting only the emitted Vary header), but stores and retrieves the cached page under the header-agnostic key. get_page_cache therefore returns whichever variant was cached first.

Impact

• Information disclosure: when a plugin varies its output on a request header (e.g. Country-Code), the variant rendered for the first anonymous visitor is served to everyone until the entry expires, leaking request-specific content across users.
• Cache poisoning: an unauthenticated attacker can prime the anonymous page cache with content rendered from attacker-chosen header values, which is then served to subsequent visitors.

Applies only when CMS_PAGE_CACHE is enabled and at least one plugin implements get_vary_cache_on().

Patches

Fixed in 5.0.8: the page cache now folds the request's values implements get_vary_cache_on().

Patches

Fixed in 5.0.8: the page cache now folds the request's values for plugin-declared vary headers into the content key. The set of vary headers is persisted on write and looked up first on read (mirroring Django's learn_cache_key/get_cache_key); a missing header-list entry degrades to a cache miss, never a wrong-variant hit.

Workarounds

Disable CMS_PAGE_CACHE, or avoid plugins that rely on get_vary_cache_on(), until upgraded.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The move_plugin admin endpoint does not prevent a plugin from being reparented under itself or one of its own descendants. Doing so creates a cycle in the plugin tree, after which the recursive descendant/ancestor SQL queries loop without terminating, stalling the request worker.

Details

move_plugin (in cms/admin/placeholderadmin.py) accepts a plugin_parent POST parameter and, for an in-placeholder move, sets the plugin's parent to the target without any cycle/ancestor check. If the target parent is a descendant of the moved plugin, the resulting parent_id graph contains a cycle.

Descendant and ancestor traversal is implemented with WITH RECURSIVE CTEs (_get_descendants_cte / _get_ancestors_cte in cms/models/pluginmodel.py) that have no cycle clause or depth limit. On a cyclic tree these recurse indefinitely (PostgreSQL/SQLite) or error at the recursion limit (MySQL). get_descendants() is invoked while building the move response and on subsequent operations on the affected subtree.

Impact

An authenticated staff user with permission to change plugins in at least one placeholder can corrupt that placeholder's plugin tree, causing requests that traverse it (rendering, copy, delete) to hang and consume application workers (denial of service). The tree is also left in a corrupted state.

Requires CMS_PERMISSION/plugin-change permission on a placeholder.

Patches

Fixed in 5.0.8: move_plugin now rejects (HTTP 400) any move that would place a plugin inside itself or one of its descendants, before any tree mutation or traversal.

Workarounds

None. Upgrade is recommended.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

Summary

The django-cms frontend-editing structure endpoint

GET /<lang>/admin/cms/placeholder/object/<content_type_id>/structure/<object_id>/

did not perform an object-level authorization check for non-PageContent objects. Any authenticated, active staff user could request the structure endpoint for a frontend-editable object (a model using PlaceholderRelationField) and read its placeholder/plugin structure, even without permission to change that object and without the cms.use_structure permission that the toolbar UI requires before offering structure mode.

PageContent objects were already protected (a page-view check added in GHSA/PR #8644); this advisory covers the remaining non-PageContent branch of the same view.

Severity

The issue is staff-gated and read-only, disclosing CMS structure metadata (placeholder slot names, plugin tree, plugin identifiers/labels, object existence) rather than write access or arbitrary field data.

Affected versions

• django-cms >= 4.0.0, <= 5.0.x and 5.1.0a1 (the vulnerable non-PageContent branch was introduced with the frontend-editing endpoints in 4.0)

Patched versions

• django-cms TODO: 5.0.9

Preconditions

• An authenticated, active staff account (is_staff=True).
• The deployment exposes a non-PageContent model with django-cms placeholders / frontend editing (e.g. via PlaceholderRelationField).
• The attacker can guess or enumerate the target content_type_id and object id.
• The attacker needs no model/object change permission and no cms.use_structure permission.

Impact

A low-privileged staff user can read the editorial placeholder/plugin structure of non-PageContent objects they are not authorized to edit through the toolbar. Depending on the installed plugins and templates this may reveal placeholder names, plugin layout, plugin identifiers and the existence of objects owned by other staff users or teams. This is most relevant for deployments using third-party or custom django-cms apps that expose frontend-editable objects outside the page tree.

Proof of concept

Using django-cms' own test model placeholder_relation_field_app.FancyPoll (a non-PageContent model with a PlaceholderRelationField):

target = FancyPoll.objects.create(name="private-fancy-poll")
placeholder = rescan_placeholders_for_obj(target)["content"]
attacker = self._create_user("low_staff", is_staff=True, is_superuser=False)
# attacker has neither change_fancypoll nor cms.use_structure

with self.login_user_context(attacker):
    response = self.client.get(get_object_structure_url(target, language="en"))

# Before fix: HTTP 200, body contains '"placeholder_id": "<pk>"'
# After fix:  HTTP 404, structure not disclosed

Patch

render_object_structure now authorizes the non-PageContent branch, mirroring Placeholder.has_change_permission at the object level (honouring a custom has_placeholder_change_permission hook, otherwise falling back to the model/object change permission) and returning 404 when the user is not authorized:

else:
    content_type_obj = content_type.get_object_for_this_type(pk=object_id)
    if not _can_change_placeholder_object(request.user, content_type_obj):
        raise Http404

Workarounds

No configuration workaround. Deployments that do not register any non-PageContent frontend-editable model are not affected. Otherwise, upgrade to a patched release.

Credit

Reported by doanmanhducz.

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>

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