BinaryFormatter is a .NET serialization mechanism for turning objects into bytes and back again. It is dangerous when used with untrusted input because the deserializer can be forced to instantiate attacker-controlled object graphs, leading to code execution. Modern Microsoft guidance treats it as obsolete and unsuitable for hostile data.
What BinaryFormatter Is Used For
BinaryFormatter serializes .NET objects into a binary stream and reconstructs them later. It was designed for convenient object persistence and remoting-style workflows, not for accepting hostile or untrusted data.
That design choice matters because the deserializer is not just reading values, it is rehydrating object graphs. When the input source is not fully trusted, the format can become a code execution path rather than a data interchange format.
Why BinaryFormatter Is Dangerous With Untrusted Input
The core security problem is that deserialization can trigger type resolution, object construction, and callback behavior before the application has a chance to validate intent. An attacker who can influence the byte stream may be able to shape the object graph in ways that invoke dangerous runtime behavior.
This is why Microsoft guidance treats BinaryFormatter as obsolete for hostile data. The issue is not binary encoding itself, but the combination of rich object reconstruction and unsafe trust in externally supplied payloads. Comparable risks are widely documented in deserialization security guidance, including OWASP's insecure deserialization guidance and the .NET platform's BinaryFormatter security guidance.
Safer Alternatives and Migration Context
BinaryFormatter is usually discussed today as a migration problem. Legacy code may still depend on it for backward compatibility, but modern application design should use serializers that treat data as data, not as instructions for reconstructing arbitrary runtime objects.
That often means choosing explicit schemas, limiting accepted types, and using serializers whose behavior is predictable under adversarial input. For protocol and payload handling, the design goal is to reduce implicit object activation and keep the trust boundary centered on validated data, not on deserialization side effects. Microsoft's broader platform hardening guidance, along with System.Text.Json, reflects that safer direction.
When BinaryFormatter Still Appears in Real Systems
BinaryFormatter most often survives in older enterprise code, internal tooling, or compatibility layers where developers inherited serialized blobs from past releases. In those cases, the main challenge is not understanding the API, but understanding where the payloads come from and whether any boundary can be crossed by untrusted content.
If the format is restricted to tightly controlled, versioned, internal data, the risk is lower, but the moment the same path can receive user-controlled or network-originated content, the attack surface changes materially. The right mental model is that the serializer itself is part of the trust boundary, not a neutral plumbing component.
Risk and Threat Considerations
BinaryFormatter creates a high-impact deserialization risk because hostile input may steer object construction, invoke dangerous behaviors, and lead to code execution. The danger is amplified when applications deserialize data from files, network requests, messages, caches, or any other boundary the attacker can influence.
Failure mechanism: The deserializer accepts a crafted payload, resolves types and object relationships during rehydration, and reaches code paths that were never intended to process attacker-controlled data.
Impact: The result can include remote code execution, application compromise, privilege abuse, or a broader trust-boundary bypass, especially when the vulnerable code runs with elevated permissions or reaches sensitive resources.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V5 — File Handling | BinaryFormatter abuse is a file/payload parsing trust-boundary issue. |
| V15 — Secure Coding and Architecture | Safer serializer selection and trust-boundary design are central to preventing this class of flaw. | |
| Recommendation — Avoid deserializing untrusted files with BinaryFormatter and use explicit, validated data formats instead. Replace BinaryFormatter with explicit, schema-driven serialization in security-sensitive code. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The term centers on hostile input reaching a parser that activates unsafe behavior. |
| SC-18 — Mobile Code | BinaryFormatter can activate attacker-influenced code paths through deserialization behavior. | |
| Recommendation — Validate serialized input sources before processing and reject unexpected object graphs. Restrict or remove deserialization paths that can execute attacker-controlled logic. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Legacy serialization flaws are application security weaknesses requiring secure development controls. |
| Recommendation — Inventory and remediate unsafe deserialization uses during application security reviews. | ||
Practitioner Guidance
Why practitioners should care: Treat BinaryFormatter as a legacy compatibility risk, not a general-purpose serialization option. If it still exists in a codebase, the key question is whether every caller and every data source is fully trusted, because that assumption is what makes the mechanism survivable.
Common misunderstanding: Base64-encoding, transport encryption, or internal network placement does not make unsafe deserialization safe. The real control is eliminating or strictly constraining the deserializer path, then replacing it with a serializer that only processes expected data shapes.
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
