fix(deps): pin System.Security.Cryptography.Xml 10.0.6 for CVE-2026-26171/33116

[Aaronontheweb]

Summary

Patches two HIGH-severity DoS CVEs in System.Security.Cryptography.Xml by pinning the transitive dep to 10.0.6 via a direct PackageReference in Netclaw.Configuration, while keeping Microsoft.AspNetCore.DataProtection at 10.0.5.

• GHSA-w3x6-4m5h-cxqf / CVE-2026-26171
• GHSA-37gx-xxp4-5rgx / CVE-2026-33116

Supersedes #676 (closed).

Why not bump DataProtection to 10.0.6?

Microsoft.AspNetCore.DataProtection 10.0.6 has a regression in ManagedAuthenticatedEncryptor.CalculateAndValidateMac that breaks every IDataProtector.Unprotect call on Linux/macOS — even same-process round-trips with a fresh key ring. The MAC compare runs against an uninitialized stack buffer because the ComputeHash return value is discarded, so the time-constant compare always returns false and throws CryptographicException: The payload was invalid.

On #676 this surfaced as failures across every test touching encrypted secrets: DataProtectionSecretsProtectorTests, SecretsFileWriterTests, SensitiveStringConverterTests, ConfigFileHelperSecretsRoundTripTests, McpCommandTests.Add_With*_WritesSecretsFile, ProviderManagerViewModelTests, ProviderCommandTests, SlackAuthDoctorCheckTests, etc. — all with the same ManagedAuthenticatedEncryptor.CalculateAndValidateMac stack frame.

I reproduced locally and confirmed by decompiling both assemblies with `ilspycmd`:

• 10.0.5 lib/net10.0 assembly — correct: uses `HMACSHA256.HashData(validationSubkey, hashSource, correctHash)` where `hashSource = payloadArray[ivOffset..macOffset]`, then compares the computed hash to the payload MAC.
• 10.0.6 lib/net10.0 assembly — buggy: calls `keyedHashAlgorithm.ComputeHash(payloadArray, macOffset, eofOffset - macOffset)` (hashing the MAC region, not IV+ciphertext), throws the return value away, then compares the uninitialized `correctHash` buffer against the payload MAC.

This is the latent bug from dotnet/aspnetcore#65889. The fix (#65890, backported as #65934) merged to `release/10.0` on Mar 24, but the `dotnet/dotnet` commit 10.0.6 was built from (`47fb725a`, Mar 26) didn't include it — I verified the file at that SHA still has the pre-fix body. So the fix missed the 10.0.6 snap.

Unrelated side note: the `net10.0` assembly in 10.0.6 is also hitting the pre-`NET10_0_OR_GREATER` code path (no `HashData`, no `SetKey`/`EncryptCbc`, just `MemoryStream` + `CryptoStream`), even though the source and csproj are byte-identical to 10.0.5's snap. That's a build-environment regression in Microsoft's pipeline, separate from the MAC bug — but the combination is what makes the Managed path actively throw instead of silently using a slower code path.

How the pin works

`Microsoft.AspNetCore.DataProtection 10.0.5` declares a transitive dep on `System.Security.Cryptography.Xml 10.0.5`. Adding a direct `PackageReference Include="System.Security.Cryptography.Xml"` in `Netclaw.Configuration` (the only project that references DataProtection) lets NuGet's highest-version-wins rule promote the transitive to `10.0.6`. Verified in `project.assets.json`:

```
"System.Security.Cryptography.Xml/10.0.6": { "type": "package", ... }
```

Same pattern as petabridge/llm-email-gateway#739.

Test plan

• dotnet test src/Netclaw.Configuration.Tests/Netclaw.Configuration.Tests.csproj --filter DataProtectionSecretsProtectorTests.Round_trip_preserves_value — passes locally
• SecretsFileWriterTests.DecryptJsonLeaves_round_trips_with_encrypt — passes locally
• project.assets.json in Netclaw.Configuration shows System.Security.Cryptography.Xml/10.0.6 resolved
• Full PR validation (CI)
• Drop the pin when Microsoft.AspNetCore.DataProtection 10.0.7 ships with the ManagedAuthenticatedEncryptor fix