State plainly that no fix is planned, say why, list affected versions, give every mitigation you know, and tell users what to move to. Be specific and honest. GitHub's documentation advises that when no fix is planned the advisory should say so and, ideally, include mitigation steps.
When this happens
Common reasons: the product is end of life, the flaw is in a design that cannot change without breaking compatibility, the affected feature is deprecated, or the project has no maintainer to do the work. In each case, users still need to know. Silence leaves them guessing.
What to include
- A clear statement, early, such as "No patched version will be released for this line."
- The reason, in a sentence.
- Affected versions and components.
- Impact in plain words: what an attacker can do and what they need first.
- Mitigations: configuration changes, network restrictions, feature disablement.
- A recommended path: upgrade to a supported line, switch to a replacement, remove the feature.
- Credit for the reporter.
- Date and a contact for questions.
A short outline
| Section | Example wording |
|---|---|
| Summary | A flaw in the legacy import endpoint allows file overwrite by authenticated users |
| Status | No fix planned for versions 2.x, which are no longer supported |
| Affected | 2.0 through 2.9 |
| Mitigation | Disable the import endpoint, or restrict it to trusted accounts at the proxy |
| Recommendation | Upgrade to 4.x, where the endpoint was redesigned |
| Credit | Reported by Ana K. |
Wording to avoid
- Vague phrases like "we recommend users consider upgrading" with no mention of the vulnerability.
- Language that implies a patch is coming when it is not.
- Hiding the flaw inside release notes of a later version.
- Overstating the mitigation. Say what it covers and what it does not.
Metadata matters
If you publish through a platform such as GitHub, the form lets you set affected and patched versions. The documentation notes that without a fix version, Dependabot alerts users without suggesting a safe version. For a no fix advisory that is accurate, so leave it blank on purpose and put the explanation in the description.
Be careful about risk
An advisory for an unfixed flaw hands a roadmap to attackers. Weigh details accordingly: give users enough to act, and leave out working exploit steps. If the issue is severe and widely exploitable, consider whether an exceptional patch for the old line is worth the effort.
Try it yourself
The SCA dependency inventory demo shows how a component list reveals which version lines are in use. Click through it and think about which of your customers would see this advisory.
Click through it at your own pace, or open it full screen.
Quick check
Is it acceptable not to fix a flaw?
Sometimes, for unsupported versions or retired features. What matters is telling users clearly so they can decide.
Should we still request a CVE?
Often yes, because scanners and customers rely on identifiers to find the issue. See requesting a CVE as a maintainer.
Safeguard's SBOM and dependency scanning help people discover affected components in their own software. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
