Is CVE-2021-23758 (Ajax.NET Professional Deserialization of Untrusted Data) being exploited in the wild?

What “exploited in the wild” means for this CVE

For this vulnerability, the practical question is not whether the flaw exists in theory, but whether attackers are already using it against real systems. CISA’s inclusion of a CVE in the KEV catalogue is a strong operational signal that exploitation has moved beyond proof-of-concept risk and into active exposure. That makes the issue a live response and prioritisation problem, not just a patching backlog item.

The right first move is to confirm whether Ajax.NET Professional is present anywhere in your application estate, including legacy web apps, embedded dependencies and internet-facing services that may not be owned by the main engineering team. If the product is present, treat it as exposure until proven otherwise, because deserialization flaws are frequently reachable through ordinary request handling rather than obscure admin paths.

For a general response model, Zero-Day and Exploited Vulnerabilities Guide is the closest operational playbook for triaging actively exploited flaws, emergency mitigation and post-patch verification.

Why deserialization flaws are high-risk when exploitation is active

deserialization of untrusted data is dangerous because it can turn a parsing step into code execution or state manipulation. In .NET environments, the practical danger is often not the format alone, but the fact that object construction, type resolution and gadget chains can be abused when input reaches the deserializer without strong trust boundaries. Once that happens, the attacker may gain a path to remote code execution with the privileges of the hosting process.

This is especially serious when the affected application is externally reachable, because exploitation can be automated, repeated and blended into normal traffic. When a flaw is in the wild, defenders should assume the attacker may be probing for reachable endpoints, looking for default configurations, and using exploitation as a foothold for follow-on access, not just as a standalone crash event.

Insecure Deserialisation Guide provides the underlying mechanism detail for object injection, gadget chains and .NET deserialization risks that explain why this class of issue becomes dangerous so quickly.

CISA Known Exploited Vulnerabilities Catalog is the authoritative reference for confirming that a CVE has crossed the exploitation threshold that should drive urgent remediation.

What to do if you cannot patch immediately

If remediation must wait, shift from “patch later” thinking to containment. Reduce exposure by removing internet access to the affected application where possible, placing it behind tighter allowlists, and disabling any route that accepts attacker-controlled serialized objects. If the application must remain live, monitor for anomalous process creation, unexpected outbound connections, new files, and web requests that hit the vulnerable component repeatedly.

Because deserialization exploitation can create code execution, also review whether the application runs with excessive OS or service permissions. If the service account can reach sensitive file paths, internal systems or deployment credentials, the blast radius increases materially even when the initial exploit is limited to a single web endpoint. Where the application handles high-value secrets, rotate the exposed credentials if there is any sign of compromise.

NIST National Vulnerability Database and CVE Program are useful for verifying the canonical record, identifiers and downstream references you should use when briefing operations or tracking remediation.

Risk and Threat Considerations

Active exploitation changes the risk profile from theoretical exposure to probable targeting. A deserialization flaw that permits remote code execution can be used for web shell placement, lateral movement, data theft or persistence, especially if the vulnerable application has direct access to internal resources or secrets.

Failure mechanism: An attacker supplies crafted input that reaches an unsafe deserializer, triggers unintended object construction or gadget execution, and converts a parsing bug into code execution or another privileged action.

Impact: The affected server may be fully compromised, with the potential for service disruption, data exposure, credential theft and use of the host as a pivot point into adjacent systems.

Practitioner Guidance

What to prioritise: Inventory every deployment of Ajax.NET Professional first, then determine whether any instance is internet-facing or reachable from untrusted users. That exposure check should happen before debating whether exploitation has touched your environment.

What to verify: Confirm whether the application has already shown signs of compromise, including unusual worker-process behaviour, unexpected child processes, changed files, outbound connections, or unexplained authentication activity around the application host.

Decision rule: If the vulnerable component is still present and exposed, treat it as urgent remediation even if you have not observed abuse. If patching must wait, isolate the service and reduce its privileges until the fix is in place.

Practitioner takeaway: Once a CVE is in KEV, the key question is no longer whether exploitation is possible, but whether you have any exposed instance left that an attacker can still reach.

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2021-23758 (Ajax.NET Professional Deserialization of Untrusted Data)?
• CVE-2021-23758 (Ajax.NET Professional Deserialization of Untrusted Data)
• Is CVE-2019-18935 (Progress Telerik UI for ASP.NET AJAX Deserialization of Untrusted Data) being exploited in the wild?
• Is CVE-2021-45046 (Apache Log4j2 Deserialization of Untrusted Data) being exploited in the wild?