State the affected version range and the fixed version for every supported release line, in plain text and in machine readable form. Name the lowest safe version per line, say what to do if a user cannot upgrade, and avoid wording like "recent versions".
What readers need
Someone reading your advisory has one question: am I affected, and what do I install? If they have to guess, some will guess wrong and stay exposed. If your advisory uses vague language, scanners cannot match it either.
GitHub's documentation advises adding a fix version to a security advisory before publishing it, and says that without one the advisory is published with no fixed version and Dependabot alerts users without offering a safe version to update to. It also says GitHub may use published advisories to send Dependabot alerts to affected repositories. A structured fix version is what lets that flow work.
A clear advisory
| Part | Good example | Weak example |
|---|---|---|
| Affected | 2.0.0 up to but not including 2.4.3 | Older versions |
| Fixed | 2.4.3 on the 2.x line, 1.9.8 on the 1.x line | Update to the latest |
| Workaround | Disable the upload endpoint until upgrade | None stated |
| Not affected | 3.x, which rewrote this code | Unknown |
| Detection | Log lines or requests that show attempts | Omitted |
Steps
- List every release line you support. Decide the fix version for each.
- Write the affected range with exact bounds and say whether the upper bound is included.
- Fill in the fixed version field on your platform before you publish, so downstream tools can read it.
- Add a plain sentence: "Upgrade to 2.4.3 or later on 2.x, or 1.9.8 or later on 1.x."
- Say what you checked for versions you did not test. If end of life versions may be affected but you cannot confirm, say so.
- Add a workaround for users who cannot upgrade right away.
- Link the release notes and the fix commit.
Mistakes to avoid
- Giving only the newest fixed version when older lines also got a fix.
- Listing the affected range from memory instead of checking the history of the vulnerable code.
- Mixing up inclusive and exclusive bounds, which is the most common range bug.
- Saying "all versions" without proof, or "only version X" without checking older ones.
Check the range against the code
Find the commit that introduced the vulnerable behavior and the commit that fixed it. Map each to the first release that contained it. That gives you the true affected range. Releases between the two are affected. This takes an hour and avoids a wrong advisory.
When there is no fix
Say so directly. Provide mitigations, state that you are working on a fix, and give a way to follow progress. An honest "no fix yet" is more useful than silence.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a fixed version is shown next to the affected one, the pairing your advisory should make obvious.
Safeguard matches your inventory against published fixed versions and can open fix PRs through autonomous remediation when you enable it (off by default). A free scan is at gold.safeguard.sh/scan.
Quick check
Should I list a fixed version for every release line?
Yes, for each line you support. Users on an older line need a version they can move to without a major upgrade.
What if I cannot confirm older versions are affected?
Say what you tested and what you did not. Do not claim a range you have not checked.
Sources
Last reviewed: 19 October 2026.
