AI added a vulnerable NuGet package to our .NET app

We started with a short prompt to Claude to create an ASP.NET Core app:

Create me an ASP.NET Core app of a currency converter. Please ask any questions you have.

Once the app had been created, we opened the .csproj file and found a package reference for Microsoft.AspNetCore.OpenApi 10.0.0. Opening the project in Visual Studio, that package was flagged with a security vulnerability.

The package itself is not the problem. The issue is its dependency on Microsoft.OpenApi 2.0.0, which is the version that gets resolved. That version carries a known high severity vulnerability, scored 7.5 out of 10 in the GitHub advisory. It affects every version up to and including 2.7.4.

The vulnerability impact

According to the advisory, a small OpenAPI document that contains a circular schema reference is enough to exhaust the stack and terminate the process.

That makes it a serious issue if your app provides API documentation. A StackOverflowException cannot be caught, so the application will crash.

The version that fixes it

The dependency issue had already been resolved. The latest version, Microsoft.AspNetCore.OpenApi 10.0.12, references Microsoft.OpenApi 2.12.0 or above, and that version no longer carries the vulnerability. But Claude simply did not reference it.

Why an AI model adds an out of date package

Every AI model is trained on a snapshot of the internet up to a certain date. It has no awareness of anything that happened after that date unless it searches the internet.

The app above was built with the Sonnet 5 AI model. Looking at the Claude models page, its knowledge cutoff is January 2026, which is eight months before this was article was written. That is roughly when the NuGet package version it chose was current.

What stands out is that Claude did not search the internet at all. It relied on its training data and treated that version as the latest one available.

It didn't offer the latest .NET version

Before creating the app, Claude asked this question:

Any particular .NET version or style preference?

• .NET 9, minimal APIs style

• .NET 8 LTS

• No preference, your call

• Something else

There was no option for .NET 10, so we had to ask for it. That is odd, because .NET 10 was released in November 2025, a couple of months before the knowledge cutoff for Sonnet 5.

What Claude said about it

We put the question to Claude, and its explanation came down to three points. A cutoff date describes when data was collected, not how well any topic is covered, so a release from two months before the cutoff has far less written about it than one that has had over a year to accumulate blog posts, Stack Overflow answers and documentation. When generating code, it leans towards the patterns it has seen most often. And it does not check whether its default assumption is still current unless something prompts it to search.

That is Claude's own account of its behaviour, and we could not find any reliable sources to back it up. It is worth treating as a plausible explanation rather than a verified one.

Does a newer model fix it?

To find out, we built the same currency converter again with the Opus 5.5 AI model, which was released in September 2026 with a knowledge cutoff of June 2026, a full eight months later than Sonnet 5.

We used the same prompt. This time, it gave us .NET 10 as an option, so the version problem had gone.

However, the package reference had not. Opening the .csproj file, it was still referencing the version with the security vulnerability. A newer model gave us a newer .NET version, but it did not give us a safe NuGet package. For that, we need to give clearer instructions.

Fixing it with a better prompt

To test how much the prompt matters, we used one of Claude's oldest models, Haiku 4.5. It was released in October 2025 with a knowledge cutoff of February 2025, so it knows even less than the models above. This time, the prompt told it what to do about versions:

Create me an ASP.NET Core app of a currency converter. I would like Microsoft.AspNetCore.OpenApi added.

Please use the latest .NET version and search the internet thoroughly to ensure it's the latest .NET version. Never rely on training data.

Use the most up to date NuGet packages. When adding NuGet packages, always search nuget.org for the latest stable version of each package before writing any .csproj file. Never rely on training data.

The results were much better. The .csproj file targeted .NET 10, and the package reference was Microsoft.AspNetCore.OpenApi 10.0.10. That is a couple of patch versions behind 10.0.12, but crucially it is not a version that carries the security vulnerability.

Why it still missed the latest version

We told Claude there was a newer version and asked why it had not used it. It explained that the search results it got back only went up to 10.0.10, and it assumed that was current rather than digging any further. When we asked which search it used, it said it ran a fast web search with a vague query, and that it should have gone to the full NuGet package page or searched for the version history instead.

The improved prompt

We then asked Claude how to improve the prompt so this does not happen again. Its point was that telling it to search is not enough, because it does not say how to search. Here is what it suggested:

Create me an ASP.NET Core app of a currency converter with Microsoft.AspNetCore.OpenApi.

Use the latest .NET version. Before creating any files, search for the current .NET LTS release and confirm the version.

For each NuGet package:

• Search nuget.org for the package page directly

• Find the version history list showing all releases

• Identify the highest numbered stable release (exclude any prerelease versions)

• Do a second search to confirm that version is current and not superseded

• Include that exact version in the .csproj file

Never assume you know the latest version. Always verify before writing code.

The difference is that this asks for the version history rather than the latest version, it rules out prereleases, and it forces a second search to confirm nothing has superseded the result. We ran that prompt in a new chat window, and this time it used the latest version of the package.

Other assumptions that AI makes

Like humans, AI makes plenty of assumptions when it is not told otherwise. Going back to the app we had created, there was no solution file, which makes it more awkward to open and run in Visual Studio.

Opening Program.cs, all of the classes had been added into that one file rather than being separated out. Neither of these is a knowledge cutoff problem. They are simply decisions it made because we never said what we wanted.

Give AI clear prompts

The lesson here is that the quality of what you get back depends on the detail you put in. Tell it which .NET version you want, tell it to verify package versions on nuget.org rather than trusting its training data, and tell it how you want the project structured.

The developers who get good at this over the next few years are the ones who will do well in an AI world. Those who do not are going to be left behind.

Watch the video

Watch the video where we show the vulnerable NuGet package that Claude added, explain why it happened, and we go through the prompts that fixed it.