CVE-2026-33116 - .NET System.Security.Cryptography.Xml DoS
System.Security.Cryptography.Xml contains a denial-of-service
vulnerability across multiple release trains. Affected
applications can be disrupted when vulnerable package versions
are present in direct or transitive dependencies.
When to use it
- A .NET solution directly or transitively resolves a vulnerable
System.Security.Cryptography.Xmlpackage version. - Central package management, lockfiles, or multiple runtime trains make the effective package version hard to see from a single project file.
- XML signature, SAML, WS-Security, document verification, or inbound XML processing can reach untrusted or partner-supplied XML.
- You need a bounded dependency remediation PR or a triage note naming blocked projects, owners, and containment.
Inputs
*.csproj,Directory.Packages.props,packages.lock.json, solution files, container files, SBOMs, and generated dependency reports.- Runtime train for each project and the effective resolved package versions.
- XML signature, SAML, WS-Security, document verification, or partner XML entry points owned by the repository.
- Available
dotnet restore,dotnet list package --include-transitive, build, test, container, SBOM, and dependency scan commands.
Affected versions
- System.Security.Cryptography.Xml
>=8.0.0, <8.0.3- vulnerable;8.0.3+patched. - System.Security.Cryptography.Xml
>=9.0.0, <9.0.15- vulnerable;9.0.15+patched. - System.Security.Cryptography.Xml
>=10.0.0, <10.0.6- vulnerable;10.0.6+patched.
Indicator-of-exposure
You are exposed if any project in the solution directly or transitively resolves a vulnerable version.
Quick checks:
dotnet list package --include-transitive | grep -i System.Security.Cryptography.Xml
Remediation strategy
- Upgrade the package to a patched version for each runtime
train in use:
- .NET 8 ->
8.0.3+ - .NET 9 ->
9.0.15+ - .NET 10 ->
10.0.6+
- .NET 8 ->
- Refresh lockfiles / central package management references.
- Rebuild and redeploy all affected services.
- Prefer aligning SDK/runtime baselines with patched lines.
The prompt
You are remediating CVE-2026-33116 in a .NET repository.
Output exactly one of:
- A PR that upgrades vulnerable package versions and updates
all dependency state files, or
- TRIAGE.md with concrete blockers and containment.
## Step 0 - Detect
1. Enumerate all `*.csproj`, `Directory.Packages.props`, and
`packages.lock.json` references to
`System.Security.Cryptography.Xml`.
2. Determine the runtime train (8/9/10) for each project.
## Step 1 - Remediate
1. Upgrade to minimum patched versions per train:
8.0.3 / 9.0.15 / 10.0.6 (or newer compatible).
2. Regenerate lockfiles and central package references.
## Step 2 - Verify
1. `dotnet list package --include-transitive` shows no
vulnerable versions.
2. Build/test pipelines pass for all touched projects.
## Stop conditions
- Upgrade introduces unresolved compile/runtime breakage.
- Runtime train is pinned by an external dependency and cannot
be updated safely this sprint.
If stopped, write TRIAGE.md with blocked projects,
short-term containment, owner, and follow-up date.
Verification - what the reviewer looks for
- Dependency output shows no vulnerable versions.
- Updated lockfiles are committed.
- CI validates build and tests after remediation.
Output contract
- Reviewer-ready PR upgrading every controlled runtime train to a patched
System.Security.Cryptography.Xmlversion and refreshing lockfiles or central package references. - Evidence showing no direct or transitive project still resolves a vulnerable package version.
- Operator notes naming affected services, XML processing surfaces, redeploy needs, and any blocked runtime train.
TRIAGE.mdwhen a runtime train, transitive pin, or external dependency prevents safe remediation in this repository.
Watch for
- Multiple projects in one solution pinned to different trains.
- Central package management overriding project-level updates.
- Stale lockfiles masking effective package resolution.