Skip to content

Pin System.Security.Cryptography.Xml to 8.0.3 in tests#2232

Merged
nblumhardt merged 2 commits into
serilog:devfrom
ArieGato:fix/test-deps-cryptography-xml-cve
May 2, 2026
Merged

Pin System.Security.Cryptography.Xml to 8.0.3 in tests#2232
nblumhardt merged 2 commits into
serilog:devfrom
ArieGato:fix/test-deps-cryptography-xml-cve

Conversation

@ArieGato

@ArieGato ArieGato commented May 1, 2026

Copy link
Copy Markdown
Contributor

Closes #2233.

Summary

Pins System.Security.Cryptography.Xml to 8.0.3 as a direct PackageReference in Serilog.Tests for the net8.0, net9.0, and net10.0 legs.

The vulnerable 8.0.2 is brought in transitively via System.ServiceModel.Primitives 8.1.0 (which itself is brought in by System.ServiceModel.Http 8.1.0). On the 8.x line, 8.0.3 is the first patched version per the Microsoft advisories.

Currently, a fresh dotnet restore against dev fails with NU1903 for two high-severity CVEs:

Both were published 2026-04-14, after the last green CI run on dev.

Why pin instead of bump

There is no 9.x line of System.ServiceModel.*; Microsoft jumped from 8.x to 10.x, and System.ServiceModel.Primitives 8.1.2 (latest 8.x) still pins the vulnerable 8.0.2. Bumping to 10.x changes the dep graph more broadly. Pinning the transitive directly is the minimal, surgical fix that keeps the rest of the graph intact.

The net462/net48 legs are unaffected: on .NET Framework, assemblies of System.ServiceModel are provided by the framework itself, so they don't pull System.Security.Cryptography.Xml 8.0.2 transitively. No pin is needed there.

Test plan

  • dotnet restore clean (no NU1903)
  • dotnet build -c Release clean — 0 warnings, 0 errors
  • dotnet test test/Serilog.Tests — 815/815 passing on net8.0, net9.0, net10.0
  • Serilog.ApprovalTests passes (no public-API drift)
  • CI on windows-latest covers the net48/net462 legs

Closes high-severity CVE-2026-33116 and CVE-2026-26171 pulled in
transitively via System.ServiceModel.Primitives 8.1.0 on the
net8.0/9.0/10.0 test legs.
@Numpsy

Numpsy commented May 1, 2026

Copy link
Copy Markdown
Member

The net462/net48 legs use System.ServiceModel.* 4.10.3

Is there actually a need for the .NET Framework builds to use the System.ServiceModel NuGet package at all, or can they just use the in-box System.ServiceModel version? (Its built in to Framework, but not Core).

@ArieGato

ArieGato commented May 1, 2026

Copy link
Copy Markdown
Contributor Author

The net462/net48 legs use System.ServiceModel.* 4.10.3

Is there actually a need for the .NET Framework builds to use the System.ServiceModel NuGet package at all, or can they just use the in-box System.ServiceModel version? (Its built in to Framework, but not Core).

That is what i meant. I though that that was the version of the net framework assemblies.

@Numpsy

Numpsy commented May 1, 2026

Copy link
Copy Markdown
Member

I mean that there might not be any purpose in referencing the System.ServiceModel.Http NuGet packages in the net462 or net48 TFMs - e.g. maybe

  <ItemGroup Condition=" '$(TargetFramework)' == 'net462' ">
    <PackageReference Include="System.ValueTuple" Version="4.5.0" />
    <PackageReference Include="System.ServiceModel.Http" Version="4.10.3" />
    <PackageReference Include="System.ServiceModel.Primitives" Version="4.10.3" />
    <PackageReference Include="System.Formats.Asn1" Version="9.0.0" />
    <PackageReference Include="System.Security.Cryptography.Pkcs" Version="9.0.0" />
  </ItemGroup>

  <ItemGroup Condition=" '$(TargetFramework)' == 'net48' ">
    <PackageReference Include="System.ValueTuple" Version="4.5.0" />
    <PackageReference Include="System.ServiceModel.Http" Version="4.10.3" />
    <PackageReference Include="System.ServiceModel.Primitives" Version="4.10.3" />
    <PackageReference Include="System.Formats.Asn1" Version="9.0.0" />
    <PackageReference Include="System.Security.Cryptography.Pkcs" Version="9.0.0" />
  </ItemGroup>

could just be

  <ItemGroup Condition=" '$(TargetFramework)' == 'net462' ">
    <PackageReference Include="System.ValueTuple" Version="4.5.0" />
    <Reference Include="System.ServiceModel" />
  </ItemGroup>

  <ItemGroup Condition=" '$(TargetFramework)' == 'net48' ">
    <Reference Include="System.ServiceModel" />
  </ItemGroup>

And then the whole thing would be simpler?
(I've hit this situation at work where .NET (Core) builds needed various of these libraries updating to avoid CVEs, but the .NET Framework one didn't because it didn't use the NuGet packages at all)

@ArieGato

ArieGato commented May 1, 2026

Copy link
Copy Markdown
Contributor Author

I agree , but I don't want to change that without confirmation of one of the maintainers. Also because it's not part of this fix.

How about this?

Collapse per-TFM ItemGroups into shared .NETFramework / .NETCoreApp
groups, and switch .NET Framework targets to the in-box System.ServiceModel
reference instead of out-of-band packages.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
@ArieGato
ArieGato force-pushed the fix/test-deps-cryptography-xml-cve branch from 0d69d7c to 74c511d Compare May 1, 2026 20:35

@nblumhardt nblumhardt left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍 Thanks!

@ite-jankl

Copy link
Copy Markdown

Thank you for providing detailed MR desc. It helps a lot when sighting/assessing new releases and upgrade paths and necessity.

This was referenced Jul 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Test deps pull vulnerable System.Security.Cryptography.Xml 8.0.2 (NU1903)

4 participants