To fix a vulnerable transitive NuGet package, first find which package pulls it in, then upgrade the closest package to your direct references. If that does not clear the warning, add the fixed version as a direct reference or turn on transitive pinning with central package management.
Step 1: find the path
Use the .NET CLI to see why a package is in the graph:
dotnet nuget why MyProject.csproj Vulnerable.Package
The Microsoft documentation also lists the Visual Studio Solution Explorer dependency node and the package manager tooltips as ways to find the path.
Step 2: try the options in order
The documentation's advice is to upgrade the package closest to your direct references first. In its example, project references A, A depends on B, B depends on C, and C 1.0.0 has a known flaw. Try upgrading A. If the warning stays, try B. If it still stays, upgrade C directly.
| Option | Good for | Watch out for |
|---|---|---|
| Upgrade the top-level package | Cleanest fix | The new version may change behavior |
| Add the fixed version as a direct reference | Quick, explicit | Remove it when a parent update makes it unnecessary |
| Transitive pinning with central package management | Many projects, one place | Pack behavior, see below |
| Suppress the advisory | Only after analysis | Hides it for every project that shares it |
| Ask the parent package to update | No fix available yet | Takes time |
How transitive pinning works
Create a Directory.Packages.props at the repository root, turn on central management, and enable pinning:
<Project>
<PropertyGroup>
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
<CentralPackageTransitivePinningEnabled>true</CentralPackageTransitivePinningEnabled>
</PropertyGroup>
<ItemGroup>
<PackageVersion Include="Vulnerable.Package" Version="2.0.0" />
</ItemGroup>
</Project>
Per the documentation, this implicitly promotes a transitive dependency to a top-level one when needed. Downgrades are not allowed: pinning below the version a dependency requests raises error NU1109.
The pack caveat for library authors
If you pack a project that uses pinning, NuGet promotes the pinned packages to explicit dependencies in the nuspec. That can add dependencies your consumers did not expect, so the documentation says to evaluate pinning carefully when authoring a library.
Verify
Restore again and confirm the audit warning is gone. Then review the change in a pull request like any other dependency edit.
Try it yourself
Click through it at your own pace, or open it full screen.
Find the fixed version listed for a vulnerable component, and ask which package would need to change to reach it.
Quick check
Can I pin a transitive package to an older version?
No. Restore raises NU1109 if the pin is lower than what a dependency requests.
Is a direct reference a permanent fix?
No. The docs say to remove it once a parent update makes it unnecessary, and to keep the attributes the original reference needed.
Safeguard's autonomous remediation can propose fix pull requests. It is off by default and every category is on Manual, so a reviewer approves the change. The free scan shows what is fixable in your project today.
Sources
- Auditing package dependencies for security vulnerabilities (Microsoft Learn)
- Central Package Management (Microsoft Learn)
Last reviewed: 19 October 2026.
