Progress Telerik UI Unsafe Deserialization

In November 2024, a critical remote code execution (RCE) vulnerability was disclosed in Progress Telerik UI for WinForms, registered as CVE-2024-10013. The flaw resides in the RichTextBox control and stems from CWE-502: Deserialization of Untrusted Data. Affected versions include all builds prior to 2024 Q4 (2024.4.1113). Attackers can exploit this vulnerability by supplying maliciously crafted external document styles that the application deserializes without adequate validation or sandboxing. When triggered, this deserialization process can instantiate attacker-controlled objects and execute arbitrary code within the context of the application, leading to full system compromise.

The root cause of the issue is unsafe deserialization—a well-known vulnerability pattern in .NET environments where data from untrusted sources is converted into live objects without verifying or restricting the types being deserialized. Specifically, Telerik’s internal logic failed to properly validate the origin and structure of style definitions loaded into the RichTextBox control. If an attacker is able to influence the serialized data (for example, by embedding payloads with type metadata), and the application uses a deserializer configured with permissive settings like TypeNameHandling.Auto in Newtonsoft.Json or BinaryFormatter, the system becomes vulnerable to remote code injection through constructor abuse, type confusion, or gadget chains.

To illustrate how common this mistake can be, consider the following real-world pattern that resembles the vulnerable behavior. A seemingly benign API accepts Base64-encoded JSON and deserializes it into a target type:

var obj = JsonConvert.DeserializeObject(json, targetType, new JsonSerializerSettings
{
    TypeNameHandling = TypeNameHandling.Auto
});

This line implicitly trusts the JSON structure to provide type information via $type, and will deserialize arbitrary types if available in the application’s assembly context. If an attacker encodes a payload such as:

{
  "$type": "System.Windows.Data.ObjectDataProvider, PresentationFramework",
  "MethodName": "Start",
  "MethodParameters": [ "cmd", "/c calc.exe" ],
  "ObjectInstance": {
    "$type": "System.Diagnostics.Process, System"
  }
}

…and submits it to the application, it could result in command execution on the server.

Mitigation requires setting TypeNameHandling = None or avoiding polymorphic deserialization from untrusted sources altogether. Developers must validate all inputs, deserialize only into known-safe DTOs, and avoid enabling features that allow automatic type resolution unless absolutely necessary.

This vulnerability highlights a common and persistent class of flaws in .NET applications: the unsafe handling of serialized data. Even mature and widely adopted libraries like Telerik UI can contain exploitable deserialization logic if input sources are not properly constrained and type resolution is not explicitly restricted. Exploits of this nature emphasize the importance of applying strict deserialization policies, performing regular reviews of third-party dependencies, and isolating components that handle complex or user-controlled data formats—such as document rendering engines—to reduce the impact of potential compromise.

We made a challenge reproducing this vulnerability, it is available for free for 1 Week via our Weekly Incident Game

• Deserialization.cs
• Deserialization.ts
• Deserialization.go
• Deserialization.py
• Deserialization.java
• Deserialization.js
• Deserialization.php