How do you patch or mitigate CVE-2021-23758 (Ajax.NET Professional Deserialization of Untrusted Data)?

CISA’s required action for CVE-2021-23758 is to apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset’s internet exposure and ensuring adherence to BOD 26-04 patching guidelines.

What patching means for an exploited deserialisation flaw

CVE-2021-23758 is not a tuning issue, it is a deserialisation risk that should be handled as a product-specific vulnerability with potential code execution impact. In practice, “patching” means applying the vendor’s fix or mitigation path exactly as instructed, then validating that the product can no longer process untrusted serialized input in the vulnerable way.

For exploited deserialisation issues, the first question is whether the affected component is still reachable in your environment. If the application is internet-facing, exposed through a reverse proxy, or embedded in a broader business service, treat the exposure as higher priority and verify whether the vulnerable code path is actually used before you defer remediation.

When the vendor provides a fix, prefer it over compensating controls. Deserialisation flaws tend to be brittle to partially block because filtering, request restrictions, or network controls can reduce risk without removing the underlying unsafe behaviour. If you need background on the underlying pattern, NHI Management Group’s Insecure Deserialisation Guide explains why object injection and gadget-chain behaviour make these flaws hard to contain with superficial filtering.

How to mitigate when patching must wait

If you cannot patch immediately, use the vendor’s mitigations as a temporary control, not a substitute for remediation. That usually means restricting access to the application, removing any route that allows untrusted remote input to reach the deserialisation sink, and reducing exposure until the fixed version or supported mitigation can be deployed.

Because CISA has already placed this issue into its active exploitation workflow, use the vulnerability as an operational priority rather than a normal backlog item. Cross-check asset exposure, internet reachability, and business criticality before deciding whether a delay is acceptable. If the mitigations cannot be applied safely, discontinuing use of the product is the right risk decision.

For prioritisation, follow the official vulnerability record and triage guidance rather than relying on the CVE title alone. CISA Known Exploited Vulnerabilities Catalog is the place to confirm the required action, while the NIST National Vulnerability Database and CVE Program help you anchor the finding to the authoritative vulnerability record.

What to verify after remediation

After applying the fix or mitigation, confirm two things: the vulnerable behaviour is no longer reachable, and there is no sign the flaw was used before remediation. For deserialisation issues, that means checking logs, application errors, unusual requests, and any evidence of unexpected process execution or post-exploitation activity around the affected service.

If the component handled credentials, tokens, or privileged session material, rotate what may have been exposed and invalidate sessions where feasible. Even when the vulnerability is described as deserialisation, the practical consequence can be broader compromise of the application’s trust boundary, so post-fix validation should include identity and access review for the affected service and any adjacent accounts.

Risk and Threat Considerations

Deserialisation flaws are attractive to attackers because they can convert a single crafted request into code execution or deeper application control. The main operational risk is not just exploitability, but the difficulty of proving that a short-term mitigation fully closes the unsafe input path.

Failure mechanism: The application accepts untrusted serialized data and reconstructs objects in a way that can trigger attacker-controlled behaviour, especially when gadget chains or dangerous type handling are available.

Impact: An attacker may gain remote code execution, alter application behaviour, or use the compromised service as a foothold for broader intrusion, so delayed remediation increases both exposure time and compromise uncertainty.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Patched exploited CVEs require prioritised vulnerability remediation and exposure validation.
Recommendation — Prioritise and remediate the exploited vulnerability, then verify exposure is removed.
NIST CSF 2.0	PR.AA-01 — Identity Management, Authentication and Access Control	Post-exploit review may require checking whether the flaw exposed access paths or privileged sessions.
Recommendation — Review and revoke affected access paths if the service or sessions may have been exposed.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	Deserialisation vulnerabilities stem from unsafe handling of untrusted input into application logic.
	SI-2 — Flaw Remediation	The question is specifically about patching or mitigating an exploited product flaw.
Recommendation — Validate and constrain untrusted input before it reaches deserialisation logic. Apply the vendor fix or approved mitigation and document the remediation status.
OWASP ASVS	V1 — Encoding and Sanitization	Unsafe deserialisation is an input-handling weakness that requires strict treatment of untrusted data.
Recommendation — Constrain and sanitise untrusted data before application processing.
MITRE ATT&CK	T1059 — Command and Scripting Interpreter	Successful deserialisation exploitation can lead to code execution on the target system.
Recommendation — Hunt for post-exploitation command execution if the service was exposed.

Practitioner Guidance

What to prioritise: Patch the externally reachable instance first, then work inward to less exposed deployments. If multiple assets use the same component, treat them as a shared-risk population and verify each one separately instead of assuming one remediation covers all instances.

What to verify: Confirm that the mitigation or patch changes the deserialisation path itself, not just the network path around it. If the fix depends on configuration, capture the exact setting, version, and deployment state so the control can be proven later.

Decision rule: If the product cannot be patched and the vendor mitigation cannot be applied with confidence, remove the exposure rather than carrying an active deserialisation risk into production.

Practitioner takeaway: For an actively exploited deserialisation CVE, the real control objective is to eliminate trust in untrusted input, not to assume a partial filter or perimeter restriction will hold indefinitely.