BinaryFormatter in .NET: why it is dangerous and what replaces it

Microsoft says BinaryFormatter is dangerous and cannot be made secure, and that apps should stop using it as soon as possible, even for data they believe is trustworthy. Starting in .NET 9, the in-box implementation throws exceptions on use. Move to System.Text.Json or another data only serializer.

Why it cannot be fixed

Microsoft's guide compares calling BinaryFormatter.Deserialize on a payload to launching it as an executable. The formatter lets the data influence control flow inside your process, so a malicious payload can run code, cause denial of service or leak information.

The guide also says that a custom SerializationBinder or other configuration switch cannot fully mitigate the denial of service category, that .NET treats the behavior as by design, and that .NET does not commit to publishing patches for bypasses. OWASP's cheat sheet agrees: it says BinaryFormatter "cannot be secured."

Related types to avoid

The same article warns against SoapFormatter, LosFormatter, NetDataContractSerializer and ObjectStateFormatter. All of them perform unrestricted polymorphic deserialization and are dangerous in the same way.

Safer replacements

Microsoft lists these in box options for handling untrusted data safely:

• System.Text.Json for JSON.
• XmlSerializer and DataContractSerializer for XML. Do not confuse DataContractSerializer with NetDataContractSerializer.
• BinaryReader and BinaryWriter when you control a simple binary layout yourself.

using System.Text.Json;

var json = JsonSerializer.Serialize(order);
var back = JsonSerializer.Deserialize<Order>(json);

The best fit is usually a plain data transfer type with only the fields you need, so the serializer can only create types you declared.

"But the data is trusted"

The guide spends time on why this assumption fails. A desktop client talking to an on premises server, a save file users share by email, or a data file synced through cloud storage can each carry a payload across a trust boundary without anyone noticing. Moving an app from desktop to cloud also changes who the attacker is.

Migration steps

1. Search for BinaryFormatter, SoapFormatter, NetDataContractSerializer, LosFormatter and ObjectStateFormatter.
2. List what each use reads and writes, and who can write it.
3. Pick a replacement format and write a converter that runs once on existing data, in an isolated process, since reading the old format is itself the risky step.
4. Check the Microsoft BinaryFormatter migration guide for current details.
5. Add a code analysis rule or search to block new uses.

For Newtonsoft JSON users

OWASP's cheat sheet says to search for TypeNameHandling and keep it at None, or use a custom SerializationBinder as an allowlist. Checking the type after deserialization is too late because execution may already have happened.

Safeguard's SBOM and dependency scanning covers NuGet packages in your solution. A free scan is at gold.safeguard.sh/scan. For a cross language view see serialization risk across Python, Java and .NET.

Quick check

Sources

• Deserialization risks in use of BinaryFormatter and related types (Microsoft Learn)
• Deserialization Cheat Sheet (OWASP)

Last reviewed: 19 October 2026.