In vcpkg, 1.2.11#9 means upstream version 1.2.11, port version 9. The number after the hash sign counts changes to vcpkg's own packaging files, such as patches or build fixes, made without a new upstream release. It starts at 0, is omitted when 0, and resets whenever the upstream version changes.
Why a fix can hide in the port version
An advisory names an upstream version: "fixed in 1.2.12". But a packaging team may patch a vulnerable release without waiting for a new upstream tag. In vcpkg that shows up as a higher port version on the same upstream version, for example 1.2.11 moving from #8 to #9.
So an alert that says "version 1.2.11 is affected" may not apply to 1.2.11#9, if the port carries a backported patch. Equally, the reverse mistake exists: assuming #9 is fixed because it is higher. Read the port's patch list and changelog to see what changed.
Debian-style backports have the same shape, as covered in how to judge a fixed version or a backported fix.
The versioning reference lists the rules for port versions: they start at 0 for the original version of the port, increase by 1 each time a vcpkg specific change is made that does not raise the package version, and reset to 0 when the package version is updated. Keep that in mind when you compare two builds of the same library.
The four version schemes
Microsoft's versioning reference defines schemes, and a manifest must use only one.
| Property | For | Sorting |
|---|---|---|
| version | Dot separated numbers | Numeric, section by section |
| version-semver | Semantic versioning | Per the semver rules |
| version-date | Dates as YYYY-MM-DD, with optional suffix numbers | By date, then suffix |
| version-string | Anything else | No sorting, exact match only |
Port versions compare after the main version: 1.2.0 is lower than 1.2.0#1, which is lower than 1.2.0#10.
The gotcha: schemes are not compared
By design, vcpkg does not compare versions that use different schemes. The documentation's example: a version-string of 7.1.3 cannot be compared with a version of 7.1.4, even though the conversion looks obvious.
For you this means a minimum version constraint may not behave as you expect if the library's port uses an unusual scheme. For version-string ports, vcpkg cannot tell whether one version is newer, so the only reliable pin is the exact one.
Steps to use this when handling an advisory
- Find the library's current port version in your vcpkg_installed tree or lockfile equivalent.
- Look up the advisory's fixed upstream version.
- If your upstream version is below it, raise the constraint or baseline.
- If it is the same, read the port's patches for the fix before deciding.
- Write the full string, including the hash and port number, in your records.
For constraint syntax, see vcpkg baseline vs overrides.
Quick check
Is 1.2.11#9 newer than 1.2.11?
Yes, by port version. Both use upstream 1.2.11, but the first has nine packaging revisions.
Why is the hash omitted sometimes?
A port version of 0 is written without the suffix, so 1.2.11 means 1.2.11 port version 0.
Safeguard's SBOM and dependency scanning can build an inventory of the components in a repository, and the free scan at gold.safeguard.sh/scan is a quick way to see what turns up.
Sources
Last reviewed: 19 October 2026.
