.NET: Pin patched OpenAPI dependencies to unblock NU1903 in sample restores - #6853
Merged
Roger Barreto (rogerbarreto) merged 2 commits intoJul 1, 2026
Merged
Conversation
Copilot
AI
changed the title
[WIP] Fix dotnet-build error due to NU1903 advisory on Microsoft.OpenApi
.NET: Pin patched OpenAPI dependencies to unblock NU1903 in sample restores
Jul 1, 2026
Roger Barreto (rogerbarreto)
marked this pull request as ready for review
July 1, 2026 10:30
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the repository’s central .NET package version pins to consume patched OpenAPI dependencies, addressing a restore-blocking NU1903 vulnerability finding coming from a vulnerable transitive Microsoft.OpenApi version.
Changes:
- Bumped
Microsoft.AspNetCore.OpenApifrom10.0.0to10.0.9in central package management. - Added an explicit central pin for
Microsoft.OpenApito2.7.5to remediateGHSA-v5pm-xwqc-g5wc.
SergeyMenshykh
approved these changes
Jul 1, 2026
Roger Barreto (rogerbarreto)
enabled auto-merge
July 1, 2026 10:36
westey (westey-m)
approved these changes
Jul 1, 2026
This was referenced Jul 4, 2026
Open
This was referenced Aug 1, 2026
This was referenced Aug 9, 2026
Maik Hasler (maik-hasler)
pushed a commit
to maik-hasler/einsatzbereit
that referenced
this pull request
Aug 11, 2026
…ft.OpenApi pin The comment claimed the pin only goes away with .NET 11. That was too pessimistic: microsoft/aspire#18919 points at dotnet/aspnetcore#67543, slated for servicing SDK 10.0.303 / ASP.NET Core 10.0.11 - weeks out, not a major version. Neither had shipped when this was written (newest SDK is 10.0.302 from 2026-07-14, newest package still 10.0.10), so the pin is still load-bearing today, but the exit condition is now stated in terms of the actual upstream fix rather than a guess. Also records two things the comment was missing. First, that this is not an Aspire problem: the vulnerable package reaches Api.csproj directly, so the Dockerfile's `dotnet restore src/Api/Api.csproj` - which never touches AppHost - breaks without the pin as well. That was confirmed empirically by deleting the pin and letting CI run: Api, ArchitectureTests and IntegrationTests all failed to restore with NU1903 while AppHost restored cleanly. Second, that NU1903 only breaks the build because this repo sets TreatWarningsAsErrors - elsewhere it is a warning you can ignore, which is why a pin like this looks unusual out of context. microsoft/agent-framework#6853 is cited as precedent: Microsoft's own repo pins this exact package for this exact advisory rather than suppressing it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V8nVn5P1xUG68NGwP6pPFa
Maik Hasler (maik-hasler)
pushed a commit
to maik-hasler/einsatzbereit
that referenced
this pull request
Aug 11, 2026
…ent in Renovate Drop the pin from 2.11.0 to 2.7.5. Both are outside GHSA-v5pm-xwqc-g5wc, but 2.7.5 is the *first* version outside it, so it stays as close as possible to the 2.0.0 that Microsoft.AspNetCore.OpenApi 10.0.10 was actually built against instead of climbing further up the 2.x line than the advisory requires. Same version microsoft/agent-framework#6853 picked for the same advisory. Deliberately unbracketed, unlike most entries in this file: a transitive pin wants to be a floor, so anything that genuinely needs a higher 2.x can still resolve up rather than hitting a version conflict. Renovate cannot delete a PackageVersion line on its own, so instead group Microsoft.OpenApi with Microsoft.AspNetCore.OpenApi and attach prBodyNotes to that group. The bump that makes the pin obsolete then arrives in a single PR that explains what the pin is for and says to delete it once the parent depends on a patched version - rather than leaving the line to rot until someone happens to read the comment in Directory.Packages.props. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V8nVn5P1xUG68NGwP6pPFa
Maik Hasler (maik-hasler)
added a commit
to maik-hasler/einsatzbereit
that referenced
this pull request
Aug 11, 2026
…ft.OpenApi to 2.7.5 (#1760) * chore(deps): drop the stale MessagePack pins and @types/node, declare Microsoft.OpenApi Audit of every NuGet, npm and container dependency for whether it is still carrying weight. Three things were not: MessagePack / MessagePack.Annotations were pinned to 3.1.8 in Directory.Packages.props without any project referencing them - pure transitive pins. Their only consumer is StreamJsonRpc 2.25.29 (pulled in by Aspire.Hosting, so AppHost and the integration/visual test projects only, never the published API image), which asks for MessagePack 2.5.302. That version sits outside every published advisory range - the MessagePack advisories cover (, 2.5.301) and [3.0.0, 3.1.7) - so the pin no longer buys any security, and dropping it stops force-upgrading StreamJsonRpc across a MessagePack major version it was not compiled against. Microsoft.OpenApi is the opposite case and is deliberately kept: Microsoft.AspNetCore.OpenApi 10.0.10 depends on exactly 2.0.0, which is inside GHSA-v5pm-xwqc-g5wc ([2.0.0-preview.11, 2.7.4], High), so the 2.11.0 pin is load-bearing. It is also consumed directly in source - Program.cs uses OpenApiInfo, OpenApiSchema and OpenApiSpecVersion - so Api.csproj now declares it as a real PackageReference instead of leaning on Microsoft.AspNetCore.OpenApi to drag it in, and the pin carries a comment recording why it sits above what the framework package asks for. @types/node was unused: nothing under frontend/src touches a Node global, and tsconfig only includes src, so the config files that might have needed it are not type-checked anyway. Every other direct reference checked out as genuinely used. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V8nVn5P1xUG68NGwP6pPFa * chore(deps): drop the explicit Microsoft.OpenApi reference, record why the pin has no alternative Two corrections to the previous commit, both from review feedback. Declaring Microsoft.OpenApi as its own PackageReference in Api.csproj was an unusual thing to do - it is normal to consume it transitively through Microsoft.AspNetCore.OpenApi and never name it, which is what this project did before and does again now. It compiled either way; the explicit reference bought nothing that justified being the odd one out. The comment on the version pin also failed to answer the obvious question: why not just upgrade Microsoft.AspNetCore.OpenApi and get a patched Microsoft.OpenApi with it? Because there is nothing to upgrade to. Every Microsoft.AspNetCore.OpenApi 10.0.x - checked 10.0.6 through the newest, 10.0.10 - depends on exactly Microsoft.OpenApi 2.0.0, squarely inside GHSA-v5pm-xwqc-g5wc's affected range. The first release that moves off it is 11.0.0-preview, which asks for [3.9.0, 4.0.0) and is clear of the advisory. So on .NET 10 the transitive pin is the only lever there is, and the comment now says so along with the condition for deleting it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V8nVn5P1xUG68NGwP6pPFa * docs: record the real exit condition and the evidence for the Microsoft.OpenApi pin The comment claimed the pin only goes away with .NET 11. That was too pessimistic: microsoft/aspire#18919 points at dotnet/aspnetcore#67543, slated for servicing SDK 10.0.303 / ASP.NET Core 10.0.11 - weeks out, not a major version. Neither had shipped when this was written (newest SDK is 10.0.302 from 2026-07-14, newest package still 10.0.10), so the pin is still load-bearing today, but the exit condition is now stated in terms of the actual upstream fix rather than a guess. Also records two things the comment was missing. First, that this is not an Aspire problem: the vulnerable package reaches Api.csproj directly, so the Dockerfile's `dotnet restore src/Api/Api.csproj` - which never touches AppHost - breaks without the pin as well. That was confirmed empirically by deleting the pin and letting CI run: Api, ArchitectureTests and IntegrationTests all failed to restore with NU1903 while AppHost restored cleanly. Second, that NU1903 only breaks the build because this repo sets TreatWarningsAsErrors - elsewhere it is a warning you can ignore, which is why a pin like this looks unusual out of context. microsoft/agent-framework#6853 is cited as precedent: Microsoft's own repo pins this exact package for this exact advisory rather than suppressing it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V8nVn5P1xUG68NGwP6pPFa * chore(deps): pin Microsoft.OpenApi to 2.7.5 and group it with its parent in Renovate Drop the pin from 2.11.0 to 2.7.5. Both are outside GHSA-v5pm-xwqc-g5wc, but 2.7.5 is the *first* version outside it, so it stays as close as possible to the 2.0.0 that Microsoft.AspNetCore.OpenApi 10.0.10 was actually built against instead of climbing further up the 2.x line than the advisory requires. Same version microsoft/agent-framework#6853 picked for the same advisory. Deliberately unbracketed, unlike most entries in this file: a transitive pin wants to be a floor, so anything that genuinely needs a higher 2.x can still resolve up rather than hitting a version conflict. Renovate cannot delete a PackageVersion line on its own, so instead group Microsoft.OpenApi with Microsoft.AspNetCore.OpenApi and attach prBodyNotes to that group. The bump that makes the pin obsolete then arrives in a single PR that explains what the pin is for and says to delete it once the parent depends on a patched version - rather than leaving the line to rot until someone happens to read the comment in Directory.Packages.props. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V8nVn5P1xUG68NGwP6pPFa * Revert "chore(deps): group Microsoft.OpenApi with its parent in Renovate" Renovate has no mechanism to delete a PackageVersion entry when a different package reaches a given version, so the rule could only group the two packages and attach a note to the resulting PR. That is a reminder dressed up as automation, and it buys too little to justify a permanent packageRule plus a paragraph of prBodyNotes that has to be kept true. Drops the rule and the sentence in Directory.Packages.props that pointed at it. The exit condition stays documented where the pin itself lives, which is where someone touching it will actually be looking. The Microsoft.OpenApi 2.11.0 -> 2.7.5 change from the same commit is deliberately kept. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V8nVn5P1xUG68NGwP6pPFa * docs: replace the Microsoft.OpenApi pin comment with a pointer to #1762 Per review on #1760. The rationale for the pin was a 28-line block sitting in the middle of a version list, which is the wrong place for it - the detail is only ever needed by whoever eventually removes the pin, and that is a task, not a fact about the file. Moved it to #1762 and left a single line naming the advisory and the exit condition. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V8nVn5P1xUG68NGwP6pPFa * docs: drop the remaining Microsoft.OpenApi pin comment Per review on #1760. #1762 already carries the full rationale and the removal criteria, so the one-line pointer was redundant with it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V8nVn5P1xUG68NGwP6pPFa --------- Co-authored-by: Claude <noreply@anthropic.com>
This was referenced Aug 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation & Context
dotnet-buildwas blocked across TFMs byNU1903becauseAgentWebChat.AgentHostrestored a vulnerable transitiveMicrosoft.OpenApi2.0.0 (GHSA-v5pm-xwqc-g5wc). This change updates the OpenAPI dependency chain in central package management to consume patched versions without introducing a major-version override.Description & Review Guide
Microsoft.AspNetCore.OpenApifrom10.0.0to10.0.9.Microsoft.OpenApito2.7.5(patched line for the advisory).dotnet/Directory.Packages.props; no project-specific csproj overrides.What is the impact of these changes?
NU1903) caused by transitiveMicrosoft.OpenApi2.0.0.What do you want reviewers to focus on?
Microsoft.OpenApi2.7.5.Related Issue
Closes #6852
Contribution Checklist
breaking changelabel (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.