You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SerializationGuard is used when EnableUnsafeBinaryFormatterSerialization feature switch is disabled #44369
SerializationGuard logic is still used even if EnableUnsafeBinaryFormatterSerialization feature is disabled via feature switch. This brings unnecessary dependencies for size sensitive workloads.
changed the title [-] SerializationGuard is used when EnableUnsafeBinaryFormatterSerialization feature switch is disables[/-][+] SerializationGuard is used when EnableUnsafeBinaryFormatterSerialization feature switch is disabled[/+]on Nov 6, 2020
Interestingly, our implementation of Serialization Guard was the only thing that prevented the original CVE-2020-1147 PoC payload from executing correctly on .NET Core.
We've had offline discussions about enlightening other serializers like DataContractSerializer and System.Text.Json, and even third-party deserializers like JSON.NET. But TBH these discussions haven't really panned out.
The runtime crew generally likes the idea of nixing Serialization Guard entirely as a feature. I think eventually we can get there, but if we go this route it should be paired with a renewed effort to excise dangerous serialization code from the ecosystem.
That API is probably something that will never be used in modern workloads. I'm not sure we actually have to have it at all for example on in the browser.
Secondly, someone would have to have Switch.System.Data.AllowArbitraryDataSetTypeInstantiation=true option set for the exploit to work, right? We can pair that with EnableUnsafeBinaryFormatterSerialization or some other feature if that's your concern.
if we go this route it should be paired with a renewed effort to excise dangerous serialization code from the ecosystem.
Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.
This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.
Activity
Dotnet-GitSync-Bot commentedon Nov 6, 2020
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
[-] SerializationGuard is used when EnableUnsafeBinaryFormatterSerialization feature switch is disables[/-][+] SerializationGuard is used when EnableUnsafeBinaryFormatterSerialization feature switch is disabled[/+]danmoseley commentedon Nov 6, 2020
cc @GrabYourPitchforks
GrabYourPitchforks commentedon Nov 9, 2020
Serialization Guard isn't a BinaryFormatter-only thing. It's also currently used in DataSet / DataTable:
runtime/src/libraries/System.Data.Common/src/System/Data/Filter/FunctionNode.cs
Lines 515 to 519 in 96073fd
Interestingly, our implementation of Serialization Guard was the only thing that prevented the original CVE-2020-1147 PoC payload from executing correctly on .NET Core.
We've had offline discussions about enlightening other serializers like DataContractSerializer and System.Text.Json, and even third-party deserializers like JSON.NET. But TBH these discussions haven't really panned out.
The runtime crew generally likes the idea of nixing Serialization Guard entirely as a feature. I think eventually we can get there, but if we go this route it should be paired with a renewed effort to excise dangerous serialization code from the ecosystem.
marek-safar commentedon Nov 10, 2020
That API is probably something that will never be used in modern workloads. I'm not sure we actually have to have it at all for example on in the browser.
Secondly, someone would have to have
Switch.System.Data.AllowArbitraryDataSetTypeInstantiation=trueoption set for the exploit to work, right? We can pair that withEnableUnsafeBinaryFormatterSerializationor some other feature if that's your concern.Are you pointing to source generators here?
dotnet-policy-service commentedon Jan 11, 2026
Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.
This process is part of our issue cleanup automation.
dotnet-policy-service commentedon Jan 25, 2026
This issue will now be closed since it had been marked
no-recent-activitybut received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.