Unsafe deserialization remains a persistent attack vector for .NET applications that accept untrusted input. Attackers can craft payloads that execute arbitrary code during object reconstruction when type filtering is absent or incomplete.

Sites running the current LTS release of .NET on Windows Server face elevated risk when legacy BinaryFormatter usage or Newtonsoft.Json configurations with TypeNameHandling remain in place. Immediate review of all deserialization entry points is required.

#Understanding the Vulnerability

The core problem occurs when applications deserialize data without restricting allowed types. This allows attackers to instantiate unexpected classes that trigger gadget chains leading to remote code execution.

#Who Is Affected

  • Applications using BinaryFormatter, NetDataContractSerializer, or LosFormatter
  • Newtonsoft.Json consumers with TypeNameHandling set to Auto, Objects, or All
  • Any public-facing endpoint that accepts serialized objects from unauthenticated sources

#Mitigation Steps

Replace legacy serializers with System.Text.Json and enforce strict type contracts. Disable type name handling entirely unless absolutely required.

csharp 
var options = new JsonSerializerOptions
{
    TypeInfoResolver = new DefaultJsonTypeInfoResolver()
};
var obj = JsonSerializer.Deserialize<MyType>(json, options);

Add explicit type validation in a custom JsonTypeInfoResolver when polymorphic deserialization cannot be avoided. Log and reject any unknown type names at runtime.

#IIS and Hosting Hardening

  • Enable request filtering to block unusually large payloads
  • Review application pool identities and limit file system access
  • Apply the latest cumulative updates for Windows Server and the .NET runtime

Audit all third-party libraries that perform internal deserialization and update them to versions that have removed dangerous default settings. Re-test after changes with both unit tests and integration security scans.