CVE-2021-23758 is an ajax.net deserialization of untrusted data vulnerability in Ajax.NET Professional Ajax.NET Professional. CISA added it to the Known Exploited Vulnerabilities catalogue on 26 August 2026, which means attackers have used it in real attacks. The impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS).
What this vulnerability class means
deserialization of untrusted data is dangerous because it lets attacker-controlled input influence how an application reconstructs objects or executes logic. In a web component such as Ajax.NET Professional, that can turn a routine request into a path for code execution, privilege abuse, or application compromise if trust boundaries are weak.
For this reason, the exact exploit mechanics matter less than the underlying pattern: any place where the application accepts serialized state from outside the trust boundary deserves scrutiny. The official CVE Program and NIST National Vulnerability Database remain the authoritative places to confirm the record details and related vulnerability metadata.
Why it is dangerous in a legacy web component
Legacy web components are often embedded deep inside older applications, which makes them harder to inventory and easier to overlook during routine patching. When a product is also end-of-life or end-of-service, the risk rises because organisations may no longer have a vendor-supported remediation path and may need compensating controls while they plan replacement.
The danger is not only that one endpoint may be exposed. Deserialization flaws can become a gateway into broader application trust, especially when the vulnerable component handles session state, configuration objects, or privileged server-side operations. That is why vulnerability context and asset ownership are as important as the CVE label itself.
How organisations check exposure and reduce it
Exposure review starts with knowing whether the product exists anywhere in the environment, including forgotten test systems, inherited applications, and externally reachable sites. Organisations should then check whether the vulnerable instance is internet-facing, whether it is still supported, and whether the vendor has published any advisory or migration guidance for the exact deployment.
Where patching is delayed, compensate by reducing reachability, tightening request filtering, isolating the affected application, and limiting the privileges available to the process that handles the deserialization flow. A structured vulnerability programme helps turn those checks into repeatable practice, and NHIMG’s Vulnerability Management Guide is a useful reference for asset scope, prioritisation, exceptions, and verification.
Detection and post-compromise review
Deserialization exploitation is often discovered indirectly, through unusual requests, unexpected process behaviour, unexplained file changes, or suspicious outbound connections from the affected host. If a system may have been exploited, review logs for evidence of command execution, web shell activity, new accounts, modified configurations, and other signs that attacker-controlled input progressed beyond the original endpoint.
Post-patch review should also look beyond the application itself. If an attacker reached the runtime, they may have accessed adjacent services, cached credentials, configuration secrets, or administrative sessions. NHIMG’s State of NHI & AI Agent Breach Report 2026 is useful background on how exposed secrets and stolen access material often turn a single compromise into lateral movement.
Risk and Threat Considerations
Exploitation of a deserialization flaw can create direct remote compromise of an application that operators may assume is low risk because it is old, internal, or lightly used. The real threat is that once attacker-controlled objects are accepted as trusted input, the boundary between a web request and server-side execution can collapse quickly.
Failure mechanism: The application interprets hostile serialized content as trusted state, allowing malicious object construction, logic abuse, or execution of unintended server-side behaviour.
Impact: Attackers can gain code execution, steal credentials or secrets held by the application, pivot to adjacent systems, and in some cases turn a single internet-facing flaw into broader environment compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical Devices and Systems Inventory | Asset inventory is central to finding where the vulnerable component exists. |
| PR.PS-04 — Log Event and Response Detection | Detection and compromise review depend on monitoring suspicious application and host activity. | |
| Recommendation — Inventory systems running the component so exposure can be assessed and retired systems found. Correlate logs and host telemetry to detect exploitation and post-compromise persistence. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Deserialization of untrusted data is an input-trust failure that this control directly addresses. |
| SC-7 — Boundary Protection | Exposure reduction for internet-facing legacy components depends on boundary restrictions. | |
| Recommendation — Reject untrusted serialized input and enforce safe parsing and validation boundaries. Restrict network reachability to the vulnerable service and segment it from sensitive assets. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | CVE exposure and compensating controls map directly to continuous vulnerability management. |
| Recommendation — Prioritise the CVE, verify deployment scope, and track remediation or containment to closure. | ||
Practitioner Guidance
Why practitioners should care: Treat this class of issue as a lifecycle problem, not just a patching problem. If the affected product is still in use, confirm ownership, validate where it is deployed, and decide whether the right answer is remediation, isolation, or retirement.
Common misunderstanding: Teams often underestimate deserialization flaws because the product is “just a component” or because the vulnerable path is not obvious in normal user flows. In practice, hidden endpoints and legacy integrations are exactly where attackers look first.
Practitioner takeaway: The safest outcome is not only to remove the vulnerable version, but to verify that no reachable path still accepts untrusted serialized data and no compromised runtime artefacts remain behind.
Related resources from NHI Mgmt Group
- CVE-2026-20131 (Cisco Secure Firewall Management Center (FMC) Software and Cisco Security Cloud Control (SCC) Firewall Management Deserialization of Untrusted Data)
- Deserialization Of Untrusted Data
- CVE-2017-9248 (Progress Telerik UI for ASP.NET AJAX and Sitefinity Cryptographic Weakness)
- What breaks when AI serving frameworks deserialize untrusted network data?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org