CVE-2026-61663 is a medium-severity (CVSS 4.3) CWE-639 vulnerability in django-cms. O3 Security confirms whether CVE-2026-61663 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
django CMS: Missing authorization in `render_object_structure` discloses non-PageContent placeholder structure to low-privileged staff
Real-World Exposure
django-cmsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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.xand5.1.0a1(the vulnerable non-PageContentbranch 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-
PageContentmodel with django-cms placeholders / frontend editing (e.g. viaPlaceholderRelationField). - The attacker can guess or enumerate the target
content_type_idand object id. - The attacker needs no model/object change permission and no
cms.use_structurepermission.
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | django-cms | all versions | 5.0.9 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for django-cms. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update django-cms to 5.0.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-61663 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-61663 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to CVE-2026-61663. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-61663 in your dependencies?
O3 detects CVE-2026-61663 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.