CVE-2025-66631 Overview
CVE-2025-66631 is an insecure deserialization vulnerability [CWE-502] in CSLA .NET, a framework used to build reusable object-oriented business layers for .NET applications. Versions 5.5.4 and below ship a WcfProxy component that relies on the obsolete NetDataContractSerializer (NDCS). Attackers can send crafted serialized payloads through the data portal to trigger remote code execution during deserialization. The maintainers, MarimerLLC, addressed the issue in CSLA version 6.0.0. Organizations running affected versions with WcfProxy configured in the data portal are exposed to unauthenticated network-based code execution.
Critical Impact
Unauthenticated attackers can achieve remote code execution by sending crafted serialized objects to a CSLA .NET data portal that uses WcfProxy.
Affected Products
- CSLA .NET versions 5.5.4 and below
- Applications using WcfProxy in data portal configurations
- Components relying on NetDataContractSerializer (NDCS) for transport
Discovery Timeline
- 2025-12-09 - CVE-2025-66631 published to NVD
- 2026-03-25 - Last updated in NVD database
Technical Details for CVE-2025-66631
Vulnerability Analysis
The vulnerability stems from CSLA .NET's WcfProxy using NetDataContractSerializer to deserialize messages received by the data portal. Microsoft deprecated NDCS because it preserves full .NET type information in the serialized stream and instantiates arbitrary types during deserialization. When a server-side data portal endpoint accepts WCF traffic, an attacker can submit a serialized object graph that references gadget chains within loaded assemblies. The deserializer reconstructs those types and invokes setters, callbacks, and converters that execute attacker-controlled logic. This pattern matches well-documented .NET deserialization gadget abuse seen with BinaryFormatter and NetDataContractSerializer. Successful exploitation grants the attacker code execution in the context of the data portal host process. The CSLA maintainers removed WcfProxy entirely in version 6.0.0 rather than attempting to harden NDCS usage.
Root Cause
The root cause is use of NetDataContractSerializer inside WcfProxy. NDCS is unsafe for untrusted input because it deserializes any CLR type embedded in the payload. CSLA .NET did not enforce a type allowlist or SerializationBinder constraints before processing inbound data portal messages.
Attack Vector
Exploitation requires network access to a CSLA .NET data portal endpoint configured with WcfProxy. The attacker crafts a WCF message containing a serialized gadget chain and submits it without authentication. The vulnerability is described in the GitHub Security Advisory GHSA-wq34-7f4g-953v and the maintainer pull request removing WcfProxy. No proof-of-concept code is publicly available at this time.
Detection Methods for CVE-2025-66631
Indicators of Compromise
- Inbound WCF requests to CSLA data portal endpoints containing NetDataContractSerializer XML namespaces or z:Type attributes referencing non-business types
- Unexpected child processes spawned by the data portal host (w3wp.exe, custom WCF service host) such as cmd.exe, powershell.exe, or rundll32.exe
- Outbound network connections from the data portal process to unfamiliar destinations following inbound WCF traffic
Detection Strategies
- Inspect application binaries for references to Csla.DataPortalClient.WcfProxy and System.Runtime.Serialization.NetDataContractSerializer
- Monitor process lineage from CSLA data portal hosts and alert on script interpreters or LOLBins launched as children
- Review WCF service configuration files for endpoints bound to CSLA data portal contracts on internet-reachable interfaces
Monitoring Recommendations
- Enable verbose WCF tracing on data portal services and forward logs to a centralized analytics platform for review
- Track .NET runtime assembly load events for unusual types resolved during deserialization
- Alert on authentication failures and anomalous payload sizes against data portal URIs
How to Mitigate CVE-2025-66631
Immediate Actions Required
- Upgrade CSLA .NET to version 6.0.0 or later, which removes WcfProxy entirely
- Inventory all applications using CSLA and identify any data portal configuration referencing WcfProxy
- Restrict network access to data portal endpoints to trusted clients via firewall or service mesh policies until patching is complete
Patch Information
The issue is fixed in CSLA .NET 6.0.0. The maintainer pull request #4018 removes the vulnerable WcfProxy proxy class. Refer to the GitHub Security Advisory GHSA-wq34-7f4g-953v for vendor guidance and the issue discussion for background.
Workarounds
- Remove WcfProxy from data portal configurations and switch to a supported proxy such as HttpProxy
- Disable any WCF endpoints that route CSLA data portal traffic until the upgrade is deployed
- Block external access to WCF data portal URIs at the perimeter and require mutual TLS for internal callers
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
