Django provides security support for its main development branch, the two most recent release series, and long-term support releases for a specified period. If you run any other series, no security fix is planned for it, so the first question to answer about any Django notice is whether your series is supported.
The support rule
Django's security policy page says that at any time the team gives official security support to several versions:
- the main development branch, which will become the next major release;
- the two most recent release series;
- long-term support releases, for a specified period.
Security issues that affect only the main branch, and no stable release, are fixed in public without going through the disclosure process. When a release is issued for security reasons, the notice includes a list of affected versions.
So for a team on an older series that is neither recent nor long-term support, a new notice may list versions you run, and no patch for you. The fix is a move to a supported series.
What the policy says about timing
The page says reports aim to be resolved within the industry standard 90 days, and confirmed high severity vulnerabilities are addressed promptly. It describes an acknowledgment of a report within three working days. These timings apply to reporters, but they tell you something useful: a notice usually arrives after private work, with a fixed release ready.
The policy page also has sections on severity levels, how Django discloses issues and who receives advance notification, and a way to request notifications. Check those sections if you distribute Django as part of a product or platform, since advance notification is aimed at specific parties.
How to hear about issues
- Follow the project's security announcements, which the policy describes as the place disclosures are made.
- Add the Python advisory records to your scanner. See where Python package advisories come from.
- Keep a table of the Django series you run in each service.
- For each notice, compare the affected list with your series.
| Your series | Likely status | Action |
|---|---|---|
| Latest series | Supported | Upgrade to the patch release |
| Previous series | Supported | Upgrade to the patch release |
| Long-term support, within its period | Supported | Upgrade to the patch release |
| Anything older | No planned fix | Plan a move to a supported series |
A note on trusting input
The policy also lists boundaries, such as sanitising user input and limits on header, URL and body size, as things Django expects you to handle at the application level. Read these when you see a report that depends on input you control.
Steps for a patch release
- Pin the new patch version in your lock file.
- Run the test suite, including a smoke test of the admin and login paths.
- Deploy to staging, then production.
- Record the version reached and the date.
Where Safeguard fits
Safeguard's SBOM and dependency scanning identifies the Django version in each service, and reachability analysis helps show whether a vulnerable path is used. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Does Django patch every old release?
No. The policy covers the main branch, the two most recent series and long-term support releases.
Are main-branch-only issues announced?
They are fixed in public without the disclosure process, since no stable release is affected.
Sources
- Django's security policies, fetched 19 October 2026.
Last reviewed: 19 October 2026.
