.Net: Pin MessagePack to 2.5.301 to fix GHSA-hv8m-jj95-wg3x in ChatWithAgent.AppHost

[Copilot]

Motivation and Context

The ChatWithAgent.AppHost sample fails the NU1903 vulnerability check: Aspire.Hosting.AppHost 13.0.0 transitively pulls MessagePack 2.5.192, which has high-severity advisory GHSA-hv8m-jj95-wg3x (LZ4 decompression AccessViolationException on malformed input).

Description

Override the vulnerable transitive MessagePack with the first patched release in the 2.5.x line (2.5.301), following the repo's existing transitive-pinning convention (e.g. SharpCompress/Snappier via MongoDB.Driver).

• dotnet/Directory.Packages.props — add MessagePack 2.5.301 PackageVersion with advisory reference.
• ChatWithAgent.AppHost.csproj — add a direct PackageReference Include="MessagePack" to force the override over the transitive 2.5.192.

Restore now resolves MessagePack/2.5.301 with no NU1903 warning.

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
• All unit tests pass, and I have added new tests where possible
• I didn't break anyone 😄

[Copilot]

Pull request overview

Pins MessagePack to a patched release to eliminate the NU1903 vulnerability finding (GHSA-hv8m-jj95-wg3x) in the ChatWithAgent.AppHost Aspire sample by overriding the vulnerable transitive dependency brought in by Aspire.Hosting.AppHost.

Changes:

• Added a centrally-managed PackageVersion for MessagePack at 2.5.301 in dotnet/Directory.Packages.props.
• Added an explicit PackageReference to MessagePack in ChatWithAgent.AppHost.csproj to force the transitive override.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
dotnet/samples/Demos/AgentFrameworkWithAspire/ChatWithAgent.AppHost/ChatWithAgent.AppHost.csproj	Adds a direct MessagePack reference so NuGet resolves the centrally pinned patched version instead of the vulnerable transitive dependency.
dotnet/Directory.Packages.props	Centrally pins MessagePack to 2.5.301 with an advisory note for consistent resolution under CPM.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Automated Code Review

Reviewers: 5 | Confidence: 94%

✓ Correctness

This PR correctly pins the MessagePack transitive dependency to 2.5.301 to fix vulnerability GHSA-hv8m-jj95-wg3x. The approach follows the repo's established convention for transitive pining (identical pattern to SharpCompress/Snappier via MongoDB.Driver at lines 176-177 of Directory.Packages.props). The central package management setup is properly utilized: version is declared in Directory.Packages.props and the project file references it without a version attribute. No correctness issues found.

✓ Security Reliability

This PR correctly pins MessagePack to 2.5.301 to remediate GHSA-hv8m-jj95-wg3x (LZ4 decompression vulnerability). The change follows the repo's established transitive-pining convention (identical pattern to SharpCompress/Snappier pins at lines 176-177 of Directory.Packages.props). Central Package Management is enabled, so the version-less PackageReference in the csproj correctly inherits from Directory.Packages.props. No security or reliability concerns.

✓ Test Coverage

This PR is a pure dependency version pin to fix a security vulnerability (GHSA-hv8m-jj95-wg3x) in a transitive dependency of a sample AppHost project. No application logic is changed, so no new unit tests are needed. The appropriate validation for this type of change is that dotnet restore resolves without NU1903 warnings, which is covered by CI build validation. Test coverage is not a concern here.

✓ Failure Modes

This PR is a straightforward, low-risk security fix that pins the MessagePack transitive dependency to 2.5.301 to remediate GHSA-hv8m-jj95-wg3x. The change follows the repo's existing central package management conventions and transitive-pining patterns. No silent failures, swallowed exceptions, or operational failure modes are introduced. Two other Aspire AppHost projects (ProcessFramework.Aspire.AppHost and ProcessFramework.Aspire.SignalR.AppHost) also transitively consume MessagePack via Aspire.Hosting.AppHost but are not addressed—however the PR title explicitly scopes the fix to ChatWithAgent.AppHost.

✗ Design Approach

The pin itself is reasonable, but the current design only overrides the vulnerable Aspire.Hosting.AppHost transitive dependency in ChatWithAgent.AppHost. Two other AppHost projects in the repo still reference the same Aspire.Hosting.AppHost package without the new direct MessagePack override, so this approach does not consistently solve the same dependency path across the repo's Aspire samples.

Flagged Issues

• The MessagePack override is only added to ChatWithAgent.AppHost.csproj, but the repo has two other AppHost projects with the same Aspire.Hosting.AppHost transitive dependency (dotnet/samples/Demos/ProcessFrameworkWithAspire/ProcessFramework.Aspire/ProcessFramework.Aspire.AppHost/ProcessFramework.Aspire.AppHost.csproj and dotnet/samples/Demos/ProcessFrameworkWithSignalR/src/ProcessFramework.Aspire.SignalR.AppHost/ProcessFramework.Aspire.SignalR.AppHost.csproj). Those projects still carry the vulnerable transitive path. The repo's existing pattern (e.g., MongoDB/CosmosMongoDB pins) is to add the override to every consuming project.

---

Automated review by rogerbarreto's agents

[github-actions]

This override only fixes this one AppHost project. Two other Aspire AppHosts reference Aspire.Hosting.AppHost without a corresponding MessagePack override (ProcessFramework.Aspire.AppHost.csproj:16, ProcessFramework.Aspire.SignalR.AppHost.csproj:16), so those restore/build paths still resolve the vulnerable transitive dependency. The repo's established pattern (see MongoDB.csproj:32-34, CosmosMongoDB.csproj:32-34) is to add the direct override to each consuming project.

[github-actions]

Flagged issue

The MessagePack override is only added to ChatWithAgent.AppHost.csproj, but the repo has two other AppHost projects with the same Aspire.Hosting.AppHost transitive dependency (dotnet/samples/Demos/ProcessFrameworkWithAspire/ProcessFramework.Aspire/ProcessFramework.Aspire.AppHost/ProcessFramework.Aspire.AppHost.csproj and dotnet/samples/Demos/ProcessFrameworkWithSignalR/src/ProcessFramework.Aspire.SignalR.AppHost/ProcessFramework.Aspire.SignalR.AppHost.csproj). Those projects still carry the vulnerable transitive path. The repo's existing pattern (e.g., MongoDB/CosmosMongoDB pins) is to add the override to every consuming project.

---

Source: automated DevFlow PR review

[rogerbarreto]

Already addressed by

• Fix MessagePack #14079