CVE-2026-63003

Executive Summary

CVE-2026-63003 is an authorization bypass vulnerability in django CMS versions prior to 5.0.9, arising from a missing object-level authorization check in the page duplication feature. A low-privileged authenticated staff user can copy the contents (placeholders and plugins) of any page in the CMS — including pages outside their authorized subtree or across sites — by submitting a crafted source value during page duplication, and the copied content is stripped of view restrictions (permissions=False), effectively exposing restricted content. The vulnerability carries a CVSS score of 6.5 (High) with a confidentiality impact rating of High, and affects any deployment running django CMS with CMS_PERMISSION enabled and page duplication exposed to staff users. The fix is available in version 5.0.9, though patch confirmation currently relies on a single source (OSV).

Technical Analysis

The vulnerability resides in the page duplication workflow of django CMS, within the administrative interface. The flaw is classified under CWE-639 (Authorization Bypass Through User-Controlled Key), indicating that a user-controlled identifier — in this case, the source page reference — is not properly validated against the requesting user's authorization scope.

The NVD description provides specific code-level details that reveal the mechanism:

1. DuplicatePageForm.source (in cms/admin/forms.py) accepts any Page object without restriction. The form field does not filter the queryset to pages the current user is permitted to access or duplicate.

2. AddPageForm — the constructor does not narrow the hidden source field to the user's accessible page set. The hidden field retains its broad, unfiltered definition.

3. AddPageForm.clean — during validation, the method does not verify that the submitted source value corresponds to a page the user is authorized to duplicate. This is the critical missing authorization check.

4. AddPageForm.save — invokes the from_source method, which performs the actual content duplication (placeholders and plugins) from the user-supplied source page.

5. duplicate (in cms/admin/pageadmin.py) and PageAdmin.has_add_permission — both perform only a coarse-grained check: whether the user is a staff member who may add a page at all. They do not verify that the user has page change or page view permissions on the specific source page being duplicated.

Attack Surface

• Precondition: The attacker must be an authenticated staff user (low-privileged) with the ability to add pages. The CMS_PERMISSION setting must be enabled (it is by default in multi-site or permission-managed deployments).
• Exposure: The admin interface page duplication endpoint/form is network-accessible.
• Data at risk: Page content — specifically all placeholders and plugins — from unauthorized pages, including pages in restricted subtrees or other sites. The duplication sets permissions=False, which strips source view restrictions, meaning the copied content becomes viewable per the new page's permissions (which the attacker controls if they can set them, or which default to public if not set).

The core issue is that the page duplication feature operates on a raw page ID (source) without mapping that ID to the user's permitted scope. This is a classic broken object-level authorization (BOLA) pattern.

Exploitation Scenarios

Note: No public PoC is available at the time of writing; the attack chain is inferred from the vulnerability class and the code-level details in the NVD description.

Step 1: Reconnaissance / Target Identification

The attacker, already authenticated as a staff user with page-add capability, identifies the target django CMS admin interface (typically at /admin/ or a custom path). The attacker enumerates page IDs within the CMS. In django CMS, pages are typically accessed and managed via the admin; page IDs are sequential integers or UUIDs depending on configuration. The attacker can identify the schema to craft a valid source value.

Step 2: Triggering the Flaw

The attacker navigates to the page duplication form (the duplicate action in the page admin). They submit the form with a crafted source field value pointing to a page ID outside their authorized subtree — e.g., a page in a different site, or a page under a restricted parent node. The hidden source field is not server-side filtered; the clean method does not verify the user's permission on that specific page.

Step 3: Payload / Execution Method

The payload is simply the page ID of the unauthorized source page. Since no object-level authorization is performed, the request is processed normally. The form submission triggers AddPageForm.save, which calls from_source and duplicates all placeholders and plugins from the unauthorized source page into a new page created in a location the attacker can control.

Critically, the duplication is performed with permissions=False, meaning the copied content does not inherit the source page's view restrictions. The attacker's new page may default to public visibility or use whatever permission settings the attacker is entitled to assign.

Step 4: Post-Exploitation Impact

The attacker now possesses a copy of restricted content (e.g., draft articles, internal documents stored as plugins or page content) on a page they control. If the new page is publicly accessible, the previously restricted content becomes exposed to unauthenticated viewers. Even if the new page is not public, the attacker retains read access to the content regardless of source-level restrictions. In multi-site deployments, content from Site A can be duplicated into Site B, breaking site isolation and potentially leaking content across organizational boundaries.

Repeated exploitation allows the attacker to bulk-dump all content from all pages in the CMS, effectively performing an unauthorized content extraction.

Impact Assessment

CVSS Breakdown (from vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N):

• Attack Vector: Network — exploited over HTTP(S) via the admin interface.
• Attack Complexity: Low — no special conditions or race conditions needed.
• Privileges Required: Low — authenticated staff user with add-page permission.
• User Interaction: None — no victim action required.
• Scope: Unchanged — the compromise stays within the CMS.
• Confidentiality: High — full content disclosure from unauthorized pages.
• Integrity: None — no data modification (duplication is read/copy only).
• Availability: None — no denial of service.

Business Impact:

• Data breach / content leakage: Sensitive or private content stored in CMS pages (e.g., pre-publication drafts, internal policy documents, client data, legally protected content) can be exfiltrated.
• Regulatory exposure: If the CMS hosts PII or protected data, unauthorized disclosure may trigger breach notification obligations.
• Compliance impact: May violate data protection requirements (GDPR, HIPAA, PCI-DSS) depending on hosted data.
• Multi-tenant / multi-site compromise: In shared installations, site isolation is broken.

Affected Systems:

• All django CMS deployments running versions prior to 5.0.9 with CMS_PERMISSION enabled.
• Deployments where staff users have page-add permissions but should not have universal read access.

Blast Radius:

• All pages in the CMS are potentially exfiltratable by any staff user, regardless of per-page permissions.
• Multi-site deployments lose cross-site content isolation.

Detection Guidance

The following detection rules target the exploitation pattern for this vulnerability. Since the vulnerability is a missing authorization check on a server-side form, the primary detection surface is anomalous access patterns to the page duplication feature, unusual source page IDs, or content-copy behavior outside normal user patterns. Note that the NVD description does not specify URL patterns or request formats, so rules are based on the admin interface and duplication behavior; adjust paths to match your deployment's actual admin URL.

Sigma Rule

title: django CMS Page Duplication Authorization Bypass (CVE-2026-63003)
id: 6a3c9e11-4c20-4f7a-8b5f-93d1e2f0a7c4
status: experimental
description: Detects attempts to exploit CVE-2026-63003 - unauthorized page duplication via missing object-level authorization check in django CMS prior to 5.0.9
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-63003
author: valtersit.com Threat Intel
date: 2026/01/01
logsource:
    category: web
    product: django
detection:
    selection_duplicate:
        cs-method: POST
        c-uri|contains: 'duplicate'
    selection_admin:
        c-uri|contains|all:
            - 'admin'
            - 'page'
    selection_staff:
        cs-username|exists: true
    condition: selection_duplicate and selection_admin and selection_staff
level: medium
falsepositives:
    - Legitimate page duplication by authorized staff users
    - Admin path customization may require tuning
fields:
    - cs-username
    - c-uri
    - src_ip
    - cs-uri-query

YARA Rule

rule django_cms_duplicate_auth_bypass_cve_2026_63003 {
    meta:
        author = "valtersit.com Threat Intel"
        description = "Detects HTTP requests attempting to exploit CVE-2026-63003 - django CMS unauthorized page duplication"
        date = "2026-01-01"
        cve = "CVE-2026-63003"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-63003"
        severity = "high"
    strings:
        $admin_path = "admin" ascii nocase
        $duplicate_action = "duplicate" ascii nocase
        $form_source = "source" ascii nocase
        $page_model = "cms/page" ascii nocase
        $post_method = "POST" ascii
    condition:
        uint16(0) == 0x0d0a and
        any of ($admin_path, $page_model) and
        $duplicate_action and
        $post_method and
        filesize < 10KB
}

Note: This YARA rule is designed for network packet captures (PCAP files) or HTTP log exports. Adjust the file-size threshold per your capture environment. It targets the HTTP request structure typical of the duplication form submission.

Suricata IDS Rule

alert http any any -> any any (
    msg:"CVE-2026-63003 - django CMS unauthorized page duplication attempt";
    flow:established,to_server;
    http.method; content:"POST";
    http.uri; content:"admin"; nocase;
    http.uri; content:"page"; nocase;
    http.uri; content:"duplicate"; nocase;
    http.request_body; content:"source"; nocase;
    classtype:attempted-user;
    reference:cve,2026-63003;
    sid:202603003; rev:1;
    metadata:created_at 2026-01-01, updated_at 2026-01-01, cve 2026-63003;
)

Elastic Detection

// EQL query for Elastic Security - detect POST requests to page duplication
sequence by host.id, user.name
  [ network where event.action == "http_request" and
    http.request.method == "POST" and
    // Admin path and duplication - adjust to match your admin URL structure
    wildcard(http.request.uri, "*admin*page*duplicate*") or
    (wildcard(http.request.uri, "*admin*") and wildcard(http.request.uri, "*duplicate*"))
  ]
  [ authentication where event.outcome == "success" and winlog.event_id == 4624 ]

Splunk SPL Query

index=web sourcetype=access_combined
| where method="POST" AND uri LIKE "%admin%" AND uri LIKE "%duplicate%"
  AND (uri LIKE "%page%" OR uri LIKE "%cms%")
| stats count by src_ip, user, uri, status
| where count > 1
| table _time, src_ip, user, uri, status, count
| sort - _time

Note: Adjust the index and sourcetype names to match your Splunk deployment. If you log request bodies, add | where _raw LIKE "%source%" to filter for requests containing the source parameter.

Wazuh OSSEC Rule

<group name="web, django_cms,">
  <rule id="646485" level="10">
    <if_sid>31100</if_sid> <!-- Adjust or remove based on your ruleset -->
    <url>admin</url>
    <url>page</url>
    <url>duplicate</url>
    <method>POST</method>
    <description>django CMS page duplication attempt - possible CVE-2026-63003 exploitation (no object-level authz on source page)</description>
    <group>web_application_attack, cve_2026_63003,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 2/4 (CLAIMED) — The patch (version 5.0.9) is claimed by a single source (OSV) and has not been independently confirmed. Verify with the django CMS project's official release notes before applying in production.

Immediate Mitigations (before patching):

1. Disable page duplication for all non-superuser staff accounts if the CMS configuration permits. If CMS_PERMISSION is enabled and duplication is not business-critical, remove the duplicate action from the page admin for low-privileged staff.
2. Review staff user roles: Audit which staff users have the add-page permission, and restrict this permission to only trusted, high-privilege users.
3. Disable CMS_PERMISSION only if your deployment does not rely on fine-grained page access control — note this is a broad mitigation and may not fully address the issue if the vulnerability also exists in non-permission mode.
4. Network-level containment: Restrict access to the admin interface (/admin/) via IP allowlisting or VPN so that only authorized staff can reach it.
5. Monitor admin logs for any page duplication activity, especially by users who would not normally duplicate pages. Alert on any duplication events targeting pages outside a user's typical scope.

Patch / Upgrade Steps:

1. Confirm the fix: Before upgrading, verify the patch by checking the django CMS changelog for version 5.0.9 (or later) and confirm the fix addresses the described authorization-bypass issues. Since patch confidence is 2/4, consider contacting the django CMS security team or waiting for independent publication of the fix.
2. Upgrade: Update django CMS to version 5.0.9 or later. Follow the standard django CMS upgrade procedure: backup the database and codebase, upgrade the package via pip (pip install --upgrade django-cms), run database migrations (python manage.py migrate), and run the application's test suite.
3. Post-upgrade verification: After upgrading, verify that the DuplicatePageForm.source field now filters pages by user permissions, and that AddPageForm.clean validates the source page against the requesting user. Test by duplicating a page outside the test user's scope and confirming the operation is denied.

Long-Term Hardening:

1. Apply the principle of least privilege to all staff accounts. Regularly audit staff permissions in the django CMS admin and remove unnecessary add-page permissions.
2. Implement a process for credential and permission review. Ensure that when staff leave the organization or change roles, their CMS permissions are revoked or adjusted.
3. Maintain an up-to-date CMS. Subscribe to django CMS security advisories and apply patches promptly.
4. Deploy Web Application Firewall (WAF) rules to monitor and potentially block suspicious duplication requests, especially those with unusual source parameters targeting pages outside expected scopes.
5. Enable audit logging for all admin operations in django CMS (using third-party packages such as django-auditlog if not built in) and integrate these logs with your SIEM for continuous monitoring.
6. Assess whether CMS_PERMISSION is strictly required. If not needed, consider disabling it to reduce the attack surface; if it is needed, ensure all permission checks are validated and tested.
7. Conduct a security review of any custom code that interacts with the page duplication feature or the Page model to ensure object-level authorization is consistently enforced.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-63003 — Official NVD record with the vulnerability description, CVSS vector, and CWE classification.
2. OSV Advisory: https://osv.dev/vulnerability/CVE-2026-63003 — The vulnerability advisory source that claims the fix in version 5.0.9 (patch confidence 2/4).
3. django CMS Official Site: https://www.django-cms.org/ — Vendor's official website; check the changelog/release notes for version 5.0.9 and future security advisories.
4. CWE-639 Reference: https://cwe.mitre.org/data/definitions/639.html — MITRE's description of the underlying weakness class (Authorization Bypass Through User-Controlled Key) for understanding the flaw mechanism.

Threat Actor Campaigns / Exploit-in-the-Wild Evidence: No exploit-in-the-wild activity, public PoC, or known threat actor campaign has been reported for CVE-2026-63003 at the time of writing. The CVE is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. However, given the relatively low complexity of the attack (no special conditions) and the high confidentiality impact for CMS deployments, organizations are advised to prioritize patching once the fix is confirmed. Monitor threat intelligence sources for any subsequent disclosure of active exploitation.