CVE-2021-23758: Ajax.NET Professional, Insecure Deserialization RCE

Executive summary

CVE-2021-23758 is a deserialization-of-untrusted-data vulnerability in Ajax.NET Professional, better known as AjaxPro, one of the earliest AJAX libraries for classic ASP.NET Web Forms applications, first released in the mid-2000s. The flaw lets an unauthenticated remote attacker send a crafted JSON request to an AjaxPro handler endpoint and have the server instantiate arbitrary .NET types, leading to remote code execution. It carries a CVSS v3.1 base score of 9.8 (critical), per the GitHub Security Advisory GHSA-6r7c-6w96-8pvw, reflecting a network-exploitable, no-authentication, no-user-interaction bug with full impact to confidentiality, integrity, and availability.

CISA added CVE-2021-23758 to its Known Exploited Vulnerabilities (KEV) catalog on 2026-08-26, with a remediation due date of 2026-09-09. KEV inclusion means CISA has confirmed evidence of active exploitation; the catalog entry lists ransomware use as “Unknown,” and we found no public reporting tying this CVE to a named threat actor or ransomware campaign. Readers should treat the KEV listing itself as the primary evidence of in-the-wild activity rather than assuming a documented campaign exists; see the exploitation section below for what is and is not publicly known.

The vulnerability was originally disclosed in December 2021 and was patched at the time. It resurfaces on KEV now most likely because unpatched, vendored copies of the DLL are still running in production five years later, a common fate for a library that predates NuGet-based dependency management and was often manually copied into application bin folders.

Affected versions

• AjaxNetProfessional (NuGet package) and related distributions AjaxPro.2, Joint.AjaxPro, and JointAjax.AjaxPro: all versions up to and including 21.11.29 are vulnerable.
• Fixed in: 21.11.29.1, released alongside the December 2021 advisory.

Despite CISA’s note that the product “may be” end-of-life, the upstream GitHub repository (michaelschwarz/Ajax.NET-Professional) has continued to receive releases well after the patch, with NuGet listing versions as recent as October 2024 (24.10.10.1). AjaxPro is not formally abandoned by its maintainer, but it is a legacy technology tied to classic ASP.NET Web Forms, a stack most organizations are actively migrating away from. In practice, exposure today comes from old internal line-of-business apps running whatever DLL version was dropped into bin/ years ago and never revisited, not from actively maintained deployments.

Vulnerability details

AjaxPro exposes server-side .NET methods to client-side JavaScript through HTTP handlers, typically reachable at a path such as /ajaxpro/*.ashx. A client-side call is serialized to JSON and posted to this handler along with a Namespace, Method, and one or more parameter objects; the server-side JsonDeserializer resolves the target type and method reflectively and deserializes the supplied parameters into corresponding .NET objects before invoking the call.

The root cause (CWE-502, Deserialization of Untrusted Data) is that this deserialization path placed no restriction on which .NET types could be instantiated from the JSON payload. An attacker who can reach any AjaxPro-exposed method that accepts a complex object parameter can substitute a malicious type reference in place of the expected parameter type. A well-known technique for turning this into code execution abuses System.Windows.Data.ObjectDataProvider, a .NET type that, when deserialized with attacker-chosen MethodName and MethodParameters values, invokes an arbitrary method on an arbitrary object, the same gadget class used broadly in .NET deserialization exploitation (e.g., via tools like ysoserial.net). Chained correctly, this yields arbitrary command execution in the context of the IIS worker process (w3wp.exe).

A public Metasploit module (submitted via rapid7/metasploit-framework PR #18494) implements this exploitation path. It targets a specific vulnerable pattern: a custom AjaxPro-exposed method that accepts an object parameter, demonstrated against an example AddItem cart method, and constructs the JSON deserialization payload against it. This detail matters operationally: exploitability is not automatic against every AjaxPro install out of the box. It depends on the target application exposing at least one AjaxPro method with a parameter type broad enough (or gadget-compatible) to be substituted. Most nontrivial line-of-business apps built on AjaxPro do expose such methods, which is why the bug is rated critical rather than theoretical, but it is not a fully generic “any AjaxPro endpoint is instantly ownable” bug from a pure black-box scan.

The fix, in commit b0e63be5f0bb20dfce507cb8a1a9568f6e73de57, adds an allow-list of permitted types for deserialization, closing the arbitrary-type-instantiation path.

Exploitation in the wild

CISA’s KEV catalog entry is, at the time of writing, the only confirmed indicator that CVE-2021-23758 is being exploited in the wild, since KEV additions require evidence of active exploitation observed by CISA or a partner. We did not find public threat intelligence naming a specific actor, campaign, or ransomware family associated with this CVE, and the KEV entry itself lists known ransomware use as “Unknown.” Be skeptical of any secondary source that asserts specific attribution (state-sponsored actors, named ransomware groups) for this CVE without citing a primary report; we found none that could be verified.

What is independently notable: this CVE has an unusually high EPSS (Exploit Prediction Scoring System) percentile, reported around the 99th to 100th percentile in vulnerability databases, indicating it scores as highly likely to see automated exploitation attempts, consistent with the availability of a public Metasploit module and a simple, well-documented HTTP-based trigger.

Patch and remediation

• Upgrade to AjaxNetProfessional 21.11.29.1 or later (current release as of late 2024 is 24.10.10.1) via NuGet. Because AjaxPro is frequently vendored as a raw DLL rather than pulled through a package manager, a source/dependency inventory of internal .NET Web Forms applications is necessary to find every copy in use. grep-ing build output or bin folders for AjaxPro.dll / AjaxPro.2.dll across internal file shares and app servers is a reasonable starting point.
• The GitHub advisory separately warns that counterfeit/backdoored copies of the AjaxPro NuGet package have circulated; obtain the library only from the official nuget.org/packages/AjaxNetProfessional/ listing or the upstream GitHub repository, not from third-party mirrors.
• If upgrading is not immediately feasible, restrict or remove network exposure to AjaxPro handler endpoints (commonly under /ajaxpro/) at the reverse proxy or WAF layer, and audit which server-side methods are exposed via [AjaxMethod] or [AjaxNamespace] attributes for parameter types that could be gadget targets.
• Given the age of the underlying technology (classic ASP.NET Web Forms), organizations should treat this KEV entry as a prompt to evaluate whether the affected application should be migrated off AjaxPro entirely rather than simply patched, consistent with CISA’s note that the product may be nearing end-of-support in practice even where the maintainer continues to ship builds.

Detection

Because this is an HTTP-delivered, pre-authentication exploit, detection should focus on web server logs and endpoint telemetry on IIS hosts running AjaxPro-based applications:

• IIS/access logs: POST requests to paths matching /ajaxpro/*.ashx (or other configured AjaxPro handler paths) with unusual frequency, from unexpected source IPs, or immediately followed by anomalous process activity.
• Request body inspection: JSON or urlencoded bodies containing type strings such as System.Windows.Data.ObjectDataProvider, MethodName, MethodParameters, ObjectInstance, or references to System.Diagnostics.Process, all hallmarks of ObjectDataProvider-based .NET deserialization gadgets and are not legitimate AjaxPro traffic.
• Process telemetry: w3wp.exe (or the relevant application pool worker process) spawning cmd.exe, powershell.exe, csc.exe, or unexpected child processes is a strong indicator of successful exploitation on IIS.
• File/DLL inventory: presence of AjaxPro.dll, AjaxPro.2.dll, or AjaxNetProfessional.dll with a file version predating 21.11.29.1 anywhere in a web application’s bin directory should be treated as an exposed, unpatched instance until proven otherwise.
• EDR/AV: alert on newly dropped executables or scripts in IIS temp/upload directories written by the worker process account shortly after AjaxPro handler requests.

No CVE-specific IOCs (hashes, C2 domains) have been publicly published for this vulnerability as of this writing; detection should rely on the behavioral and log-based indicators above rather than static signatures.

References

• GitHub Security Advisory: GHSA-6r7c-6w96-8pvw
• Patch commit: b0e63be5f0bb20dfce507cb8a1a9568f6e73de57
• NVD entry: CVE-2021-23758
• Metasploit module PR: rapid7/metasploit-framework#18494
• CISA Known Exploited Vulnerabilities Catalog (added 2026-08-26, due 2026-09-09)