vulnerable and fixed versions" reading a security advisory

TL;DR

Every advisory answers two questions: which versions are broken and which release fixes it. Find the affected range, check your lockfile against it, then jump to at least the fixed release. The lockfile is the version that counts, not the manifest.

"vulnerable and fixed versions" reading a security advisory

Use this when

• A new advisory drops and you need to know if your stack is affected
• A scanner alert points at an advisory you havent read yet
• You are choosing which version to upgrade to for a CVE fix
• Someone asks are we affected and you need a defensible answer

Not for

• Applying the patch or testing the fix
• Advisories that describe config issues with no version component
• Reading exploit writeups (thats a different kind of advisory section)

Steps

1. Find the affected version range.

The advisory names the product and the vulnerable versions, often as a range like versions before 2.4.1, or between 3.0.0 and 3.2.7. Write down the exact range.

Expected: a clear statement like affected: all 2.x below 2.4.1.

2. Find the fixed release.

The advisory names the version that contains the fix, sometimes per major line (2.4.1 for the 2.x line, 3.2.8 for the 3.x line). Note every fixed release if there are several branches.

Expected: one target version per major line you run.

3. Check your lockfile against both.

Look up the resolved version in your lockfile for each affected service. The manifest range is not enough, the lockfile is what actually installs.

Expected: affected or not affected, per service, with the resolved version noted.

4. Watch for backports and patched forks.

Some vendors backport the fix to older branches, and Linux distros patch CVEs without changing the upstream version number. If the advisory mentions backported fixes or your distro has its own security notice, trust the distros record.

Expected: no false affected verdicts from version-only matching.

5. Pick the upgrade target.

Go to the fixed release for your major line, or the nearest release at or above it. Avoid jumping major versions in an emergency unless the advisory says the fix only exists there.

Expected: a concrete version number to bump to.

Variant phrasings

How to tell if my version is affected by a CVE

Read the affected range in the advisory, check your lockfile. If your resolved version is inside the range, you are affected.

Which version fixes this security advisory

The advisory lists fixed releases, sometimes one per supported branch. Match the fixed release to your major line.

Advisory says fixed but my version looks old

Check for backports. Distros and some vendors fix old versions in place, so the version number alone can mislead. Look for the distros own security notice.

Why it happens

Advisories are written for every consumer of the software at once, so they speak in version ranges rather than your setup. The gap between the advisorys abstract range and your concrete lockfile is where misreads happen: people check the manifest, trust the version string on a backported package, or miss that the fix only landed on one branch.

Edge cases

• Fix only on the newest major line: if the advisory fixed 5.0 but you run 4.x with no backport, you are choosing between a major upgrade and a mitigation. Make the call explicitly.
• Multiple advisories, one package: stack the fixed releases. The target version is the highest fixed release across all of them.
• Advisory version info is vague: some advisories say all versions prior to X without detailing branches. Default to the conservative read: assume affected unless your exact version is named as fixed.
• Pre-release or forked versions: if you run a fork or a pre-release, version comparison against the advisory range is unreliable. Check the actual code for the vulnerable pattern instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KnvHpfSef9mOOik00mZWVA