CVE-2025-66631 is a deserialization flaw in CSLA .NET, rated critical (CVSS 9.8) in the record. WcfProxy uses the obsolete NetDataContractSerializer, which can lead to remote code execution. Upgrade to CSLA 6.0.0 or higher, or remove WcfProxy from your data portal configuration.
What's affected
The NVD record says CSLA .NET versions 5.5.4 and below allow WcfProxy and are affected, with 6.0.0 as the fix. The GitHub advisory words it more broadly: all versions before version 6 allow WcfProxy. The safe reading is that anything older than 6.0.0 needs attention.
Severity also differs. The record scores the issue 9.8, critical. The GitHub advisory rates it high. I did not find an explanation for the gap in the pages I fetched, so both ratings are stated here. The advisory says CSLA 6 and higher do not use WCF or NetDataContractSerializer at all.
How to check if you're exposed
Check which Csla package version each project resolves:
dotnet list package | grep -i csla
dotnet list package --include-transitive | grep -i csla
Then search configuration and code for the proxy type:
grep -rn "WcfProxy" --include=*.cs --include=*.config --include=*.json .
If WcfProxy appears in a data portal configuration, the application is using the risky path. Check client applications and the servers that host the data portal.
What to do now
- Inventory every .NET project that references the Csla package and note the version.
- Remove WcfProxy from the data portal configuration. The advisory gives this as the workaround for older versions.
- Plan the upgrade to CSLA 6.0.0 or later, which no longer uses WCF or NetDataContractSerializer.
- Restrict network access to the data portal endpoint to the clients that need it.
- Test data portal calls after changing the proxy, because CSLA 6 changes the available transports.
Why it matters
NetDataContractSerializer embeds .NET type information in the data it reads, so a hostile payload can ask the runtime to build objects the developer never expected. Microsoft treats this serializer as unsafe for untrusted input. The weakness class is CWE-502, deserialization of untrusted data.
The framework author's guidance is plain: avoid WcfProxy or move to CSLA 6, where the issue does not exist. For older line of business systems this can be a large migration, which is why the workaround of dropping the proxy is useful as a first step. The record does not list this CVE as known exploited.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is CSLA 5.5.5 or later safe?
The advisory says the problem exists in versions before 6. The record only names 5.5.4 and below, so confirm any other 5.x release against the advisory.
Can I just remove WcfProxy?
Yes, the advisory gives that as the workaround, as long as your data portal does not depend on it.
Sources
Last reviewed: 18 October 2026.
