NU1901, NU1902, NU1903 and NU1904 are NuGet Audit warnings raised during restore when a package in your graph has a known vulnerability. The last digit is the severity: 1 is low, 2 is moderate, 3 is high, 4 is critical. NU1900 and NU1905 are about the audit itself failing, not about a package.
The codes in one table
| Code | Meaning |
|---|---|
| NU1900 | Error talking to a package source while fetching vulnerability data |
| NU1901 | A package with a low severity advisory was found |
| NU1902 | A package with a moderate severity advisory was found |
| NU1903 | A package with a high severity advisory was found |
| NU1904 | A package with a critical severity advisory was found |
| NU1905 | An audit source does not provide a vulnerability database |
These come from Microsoft's NuGet Audit documentation. The data behind nuget.org's vulnerability list is the GitHub Advisory Database, so a warning means a reviewed advisory exists for that package and version.
Why NU1900 and NU1905 matter more than they look
Those two codes mean the check may not have run properly. A clean restore with a hidden NU1900 is not a clean bill of health. If you treat only NU1901 to NU1904 as meaningful, you can miss a pipeline that silently stopped auditing.
What to do when you see one
- Read the warning text. It names the package, the version and links to the advisory.
- Find out whether the package is a direct reference or arrived through another package.
- Update the package, or the package closest to your direct references, to a version that fixes the advisory.
- If no fix exists, read the advisory for mitigating factors, such as a specific framework or a function you never call.
- Only as a last step, suppress the advisory, and write down who decided and why.
Choosing which codes break the build
You do not have to treat all four the same. Microsoft's docs show one pattern: keep low and moderate as warnings, and turn high and critical into errors.
<PropertyGroup>
<WarningsAsErrors>$(WarningsAsErrors);NU1903;NU1904</WarningsAsErrors>
</PropertyGroup>
If you already use TreatWarningsAsErrors for everything, add the four codes to WarningsNotAsErrors so a newly published advisory does not break an unrelated bug fix at a bad moment. A common compromise is a dedicated audit pipeline that fails on these codes while ordinary builds only warn.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and transitive packages are listed together, because that is the first thing you need when a warning appears.
Safeguard's SBOM and dependency scanning covers NuGet projects, and you can run a free scan on a repository to see the same advisories in one list.
Quick check
Is NU1903 an error or a warning by default?
It is a warning. You choose whether to promote it to an error with WarningsAsErrors.
Does a restore with no NU19xx warnings mean my packages are safe?
No. It means no known advisory matched at that moment. Advisory data changes, so check again regularly in CI.
Sources
Last reviewed: 19 October 2026.
