CVE-2025-59682

What it actually does

django.utils.archive.extract(), used by the startapp --template and startproject --template management commands, does not fully confine archive member paths to the intended extraction directory. An archive whose entries share a common path prefix with the target directory can write files outside that directory (partial path traversal), overwriting or planting files on the local filesystem of the process that runs the command. This is a developer/CI extraction flaw, not a remotely reachable production request-handler bug.

Why it matters to the business

Operational risk is limited to teams that scaffold Django apps or projects from untrusted or third-party template archives (developers’ workstations and CI/CD jobs), not typical internet-facing Django sites. Successful abuse could overwrite nearby files or plant code that later runs in a developer or pipeline context. Urgency is low: CVSS 3.1, EPSS about 0.9% with only a small 30-day rise (0.0085 to 0.0091), not on KEV, no ransomware association, exploit maturity none, and roughly a year since publication without known in-the-wild use. Django is widely deployed, so many engineering environments have the affected CLI, but only template-consuming workflows are in scope.

How an attack unfolds

An attacker who can get a target to consume a Django project or app template archive (public template, compromised internal archive, or social engineering) includes members whose paths share a prefix with the destination directory. When a developer or automation runs startproject --template or startapp --template, extract() treats those members as in-scope and writes them adjacent to or outside the intended tree. Follow-on impact depends on what is overwritten (for example settings, hooks, or scripts later executed in that environment). There are no named threat actors, KEV listings, or ransomware campaigns tied to this issue, and no public exploit maturity.

How to fix it

Upgrade Django to a fixed release: 4.2.25 or later on 4.2, 5.1.13 or later on 5.1, or 5.2.7 or later on 5.2 (upstream fix 57d20b2485e7cd2f029dbf49fb5510b2a6f12c48). Treat untrusted --template archives as untrusted code: only scaffold from internally reviewed templates, and avoid piping third-party archives into startapp/startproject until patched. Do not apply unrelated libpcap/tcpdump package notes to this Django issue.

How to confirm the fix worked

Confirm the running Django version is at least 4.2.25, 5.1.13, or 5.2.7 (python -c "import django; print(django.get_version())" or equivalent package metadata). Inventory CI and developer scripts for startproject/startapp --template usage and ensure those environments are patched. After upgrade, scaffolding from a reviewed template should only create files under the intended project/app directory; unexpected sibling or parent-directory writes indicate residual exposure or a still-unpatched interpreter.

Typical attack path

1. Gain the ability to supply a Django startproject/startapp template archive the victim will extract.
2. Include archive members whose paths share a prefix with the intended extraction directory so they are not fully confined.
3. Deliver the archive via a template URL, shared file, internal repo, or other channel the victim trusts.
4. Victim or CI runs startproject --template or startapp --template against the archive.
5. extract() writes files outside the intended project/app directory.
6. Attacker relies on those planted or overwritten files being used later on the developer host or in CI.

How to detect it

This is a local extraction issue with no network exploit signature and no associated threat-actor playbooks. Hunt developer and CI history for django-admin/manage.py/python -m django startproject or startapp invocations that pass --template, especially against HTTP(S) URLs or unpacked third-party archives around the time a new project was created. Review the parent of the created project/app for unexpected files written at extract time (timestamps aligned with the command). Application access logs will not show this; useful sources are shell history, CI job logs, and endpoint file-creation telemetry on engineering hosts. Absence of those commands is strong evidence it was not exercised.

• startproject --template
• startapp --template
• django-admin startproject
• django-admin startapp
• python -m django startproject
• python -m django startapp
• django.utils.archive.extract

What your security team should do

• Patch Django to 4.2.25 / 5.1.13 / 5.2.7 or later in developer images, laptops, and CI that run management commands; this is sufficient given low CVSS/EPSS and no KEV deadline.
• Find startproject --template and startapp --template usage in build scripts and docs; restrict templates to reviewed internal sources.
• Do not prioritize this as a production web-tier emergency; it is not a remote unauthenticated Django request-path issue.
• Revisit only if template-from-URL workflows are common or if exploit activity appears later (current maturity is none).