Not necessarily. Some projects list only the versions they support in an advisory. Django says so directly: older versions may also be affected, but the team does not investigate them and will not patch them. If you run an unsupported version, treat its status as unknown, not as safe.
What the Django policy says
The Django security policy states that official security support covers several versions at a time: the main development branch, the two most recent release series, and long-term support releases for a specified period. When a release is issued for security reasons, the accompanying notice includes a list of affected versions. The policy says that list is comprised solely of supported versions. Older versions may also be affected, but the team does not investigate to determine that, and will not issue patches or new releases for them.
This is not unique to one project. Any project that limits support will have versions it never checked. Absence from the affected list means "not examined", which is different from "not vulnerable".
Why it catches scanners out
A scanner reading an advisory sees affected ranges. If the range starts at a supported series, a version older than that may fall outside the range on paper. Your scanner stays quiet. The code may be just as vulnerable.
This is a quiet failure mode, and it hits teams that postpone upgrades. The older the version, the less likely anyone checked it.
Steps
- Find the support policy of the project, usually a page or a table in the documentation or in SECURITY.md.
- Compare your version to the supported list. Is your series still supported, and until when?
- If it is supported, upgrade to the patched release in your series.
- If it is not supported, assume it may be affected by anything fixed in newer series.
- Read the advisory for the supported lines, and look at the vulnerable component. Check whether the same code exists in your older version.
- Plan an upgrade to a supported series. A backport from someone else is not a safe substitute unless you trust and can verify the source.
| Your version status | What you can say | What to do |
|---|---|---|
| Supported, in affected range | Affected | Upgrade to the patched release |
| Supported, outside range | Not affected per project | Note the source |
| Unsupported, older than listed | Unknown | Upgrade to a supported series |
Why "unknown" is a useful label
Unknown pushes you to act. If your register has only "affected" and "not affected", unsupported versions get filed under the second by default. Add a third state and make unknown count toward your risk list. Our post on end of life software and scan results explains the same effect for retired software.
What about distribution packages
If you consume the library through an operating system package, the distributor may maintain fixes for older versions. Check their security tracker rather than relying on the upstream version number. See how backported fixes show up in version numbers.
Where Safeguard fits
Safeguard's dependency scanning and SBOM show exactly which versions of a library you run across repositories, so unsupported series stand out for review. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Pick a component and look at how version and usage are weighed together.
Quick check
If my version is not listed as affected, am I safe?
Only if the project actually checked your version. For unsupported versions, the Django policy says it does not investigate them.
What is the safest fix for an unsupported version?
Upgrade to a supported release series that carries the patch.
Sources
Last reviewed: 19 October 2026.
