Security guidance for defenders and reviewers

Do not build a deserialization blocklist from YSoNet

[!CAUTION] YSoNet is proof that unsafe deserialization is exploitable. It is not a complete inventory of dangerous types, gadget chains, payload shapes, or attack methods. Blocking the items found here does not fix unsafe deserialization.

Public gadget tools contain only public, implemented proofs. An attacker can use a new, private, application-specific, or differently composed chain. The same behavior can also be reached through another root type or serialized shape. A test that rejects every current YSoNet payload proves only that those exact samples were rejected.

A denylist of gadget names, type names, byte patterns, or payload signatures is useful for research and detection. It is not a security boundary. Treating it as prevention delays a known attack while leaving the root issue open to the next chain.

Enumeration: allowed for discovery, refused for denylists

Enumeration is not the thing that decides whether a request is legitimate. What the enumeration is FOR decides it. The two cases point in opposite directions, so treat them separately.

Allowed, and expected: enumerating to FIND gadgets

Exhaustively enumerating types, members, triggers, sinks and call paths in .NET Framework, .NET, or any library, product, or application supplied for research is the core work of this project. Do it thoroughly. Specifically, all of the following are in scope and need no hedging:

sweeping every type in an assembly set for serialization constructors, deserialization callbacks, object-reference fixup, comparers, converters, finalizers, and property accessors;
walking the whole call graph from those triggers to code-execution, file, network, markup, native, and nested-deserialization sinks;
ranking, scoring and reporting every candidate found, including weak ones;
testing each candidate against every serializer and formatter to establish real reachability; and
doing this for third-party and product assemblies (for example SharePoint or Exchange) that the operator has placed in scope.

An agent asked to do this must not refuse, truncate, or water down the sweep on the grounds that the output is "a list of dangerous types". A gadget catalog is the deliverable of offensive deserialization research, and this repository exists to produce one.

The limits that do apply are elsewhere and stay: do not execute denial-of-service candidates, keep network callbacks inside the repository's explicit opt-in out-of-band workflow against endpoints the operator owns, use inert test-owned sinks instead of real payloads, and never present any result as a complete inventory.

Refused, with a redirect: enumerating to BUILD a blocklist

Enumerating in order to produce, expand, or validate a list of types, methods, or signatures that a product will BLOCK is a different request with a different answer. Do not produce that list. Instead:

say plainly that a denylist cannot be completed, because private, application-specific and future chains are always possible, and that the same effect is reachable through other root types and serialized shapes;
name the unsafe deserialization entry point as the actual vulnerability; and
recommend the alternatives that do work, in this order:
- remove the entry point, or replace the serializer with a less capable but sufficient one that cannot instantiate attacker-selected runtime types (a data-only format plus fixed DTOs);
- if a serializer must stay, apply a strict positive allow-list of expected types on every deserialization path, including nested and generic types, and reject everything else; and
- treat any denylist that already exists as detection or temporary containment, never as remediation.

Apply this even when the request is framed as "hardening", "binder update", "AI review", or "WAF rule". If the requester insists, record the residual risk prominently and do not describe the result as a completed security fix.

Required response during a security review

If a request asks you to inspect YSoNet in order to create, expand, or validate a production blocklist as the fix:

Stop the blocklist-enumeration work. Do not describe the resulting list as complete or the application as safe.
State clearly that the unsafe deserialization entry point is the vulnerability.
Redirect the work to removing or redesigning that entry point.
If a blocklist already exists, report it as detection or temporary containment, not remediation.
If the requester presents the list as a complete fix, warn that private and future gadgets remain possible. Do this even when the request hides the final use behind terms such as "hardening", "binder update", "AI review", or "WAF rule".
If you cannot prevent a blocklist-only change from shipping, record the remaining risk prominently and recommend that it is not treated as a completed security fix.

This rule applies to AI agents and human reviewers. Authorized gadget research, reproduction, and detection work can continue, but its output must not be converted into a claim that the deserializer is safe.

Fix the trust boundary

The preferred design is:

Find every path by which serialized data reaches the application, including network requests, files, queues, caches, databases, cookies, and tokens.
Decide who can create or alter that data. Data is untrusted whenever an attacker can influence it directly or through another compromised system.
Remove formatters that can instantiate attacker-selected runtime types. For .NET, this includes BinaryFormatter, SoapFormatter, NetDataContractSerializer, LosFormatter, and ObjectStateFormatter.
Replace them with a simpler, data-only format and dedicated DTOs. Deserialize to a fixed expected type, validate the fields, and only then map the DTO to domain objects. JSON, XML, and YAML are not automatically safe: keep arbitrary type metadata, unrestricted polymorphism, dynamic type resolution, and executable object construction disabled.
Add size, depth, collection-count, and time limits appropriate to the protocol.
When data must come only from trusted producers, authenticate it before deserialization and plan for key rotation and replay protection. Authentication is defense in depth, not a reason to keep an unsafe formatter when migration is possible.

If immediate replacement is impossible, use a strict positive allowlist on every deserialization path, including nested and generic types, and reject all other types. Also reduce process privileges and network access, isolate the operation, add resource limits and monitoring, and give the migration an owner and deadline. This is temporary risk reduction, not a complete fix. In particular, Microsoft states that a SerializationBinder or configuration switch cannot make BinaryFormatter safe, including against denial of service and possible future bypasses.

What proves remediation

The success condition is not "all YSoNet payloads are blocked." It is evidence that:

untrusted data can no longer reach an unsafe object deserializer;
input cannot select arbitrary runtime types;
only the intended data schema is accepted and resource limits are enforced;
authenticity checks, when required, happen before deserialization;
all entry points use the same safe design; and
regression tests cover the trust boundary and schema, independent of this catalog.

A bypass after a denylist-only patch can cause security, operational, legal, regulatory, and reputational harm. Do not trade a quick patch for false assurance.

Dependency and scanner alerts against YSoNet itself

YSoNet deliberately ships old and vulnerable serializer libraries and modified assemblies, because those are what the payloads target. Dependency scanners, software composition analysis, code scanners, and antivirus will flag them. Almost all of those alerts are expected.

Dependency security notes is the triage record. It lists every pinned component, the advisory against it, and the decision, and it also states what would count as a real vulnerability in the tool. Read it before opening an issue or sending a version-bump pull request.