What Broke in the Dependency Graph
NuGet audit data marked a resolved package version as having a known high-severity vulnerability, which may fail restore or CI.
This is NuGet refusing to continue with a dependency graph that does not make sense. The important detail is which versions or peer requirements disagree, not just the final error code.
Repair the dependency graph
Identify the vulnerable package and which dependency brings it in with dotnet list package --include-transitive.
Upgrade to a fixed version directly, or by upgrading the parent package.
If you must ship temporarily, suppress NU190x explicitly and track remediation.
Why Resolution Broke
Usually this comes down to a direct or transitive dependency resolves to a vulnerable version, version pins or constraints prevent upgrading to a fixed version, or vulnerability data updates newly classify a version as vulnerable.
Prove the Graph Is Clean Again
dotnet restore no longer emits NU1903, or it is explicitly suppressed with intent.
The resolved graph contains the upgraded, non-flagged version.
Validation
Re-run the failing command and confirm the original code/message is gone, and confirm expected artifacts or outputs exist (packages restored, build/publish succeeds).
Examples
warning NU1903: Package 'Example.Package' 1.0.0 has a known high severity vulnerability.Mechanism
During restore, NuGet can audit packages against vulnerability data. NU1903 is emitted when a resolved version is flagged as high severity and may fail builds when warnings are treated as errors.
Keep the Dependency Graph Healthy
To prevent this, automate dependency updates and auditing in CI, and prefer lock files and periodic controlled refreshes to handle vulnerability-driven upgrades.