Ajax.NET Professional (AjaxPro) Deserialization Flaw Actively Exploited — CISA KEV Detection and Remediation Guide

On August 26, 2026, CISA added CVE-2021-23758 — a deserialization of untrusted data vulnerability in Ajax.NET Professional (AjaxPro) — to its Known Exploited Vulnerabilities (KEV) catalog. KEV inclusion is not a theoretical risk rating; it is CISA's confirmation that threat actors are exploiting this flaw in the wild right now against internet-facing .NET applications.

This is a worst-case scenario for defenders: an unauthenticated remote code execution path via arbitrary .NET class deserialization, sitting in a library that is likely end-of-life and end-of-service, embedded in legacy ASP.NET applications that many organizations forgot they were still running. If your environment hosts ASP.NET applications on IIS — especially older line-of-business apps, vendor products, or inherited codebases — you need to treat this as an active incident response trigger, not a patching ticket.

Federal Civilian Executive Branch agencies are bound by CISA's remediation directives, and CISA's guidance for this entry references compliance with BOD 26-04 (Prioritizing Security Updates Based on Risk) and CISA's Forensics Triage Requirements. Private-sector organizations should treat the same deadlines as their benchmark.

Technical Analysis

What Is Ajax.NET Professional?

Ajax.NET Professional (AjaxPro) is a legacy third-party .NET library that enables AJAX functionality in ASP.NET Web Forms applications by automatically generating JavaScript proxies for server-side methods. It works by registering HTTP handlers (typically .ashx endpoints under paths like /ajaxpro/) that accept serialized JSON payloads from the browser and deserialize them into server-side .NET objects.

AjaxPro was popular in the mid-2000s through early 2010s. That popularity is exactly the problem: it is baked into thousands of legacy applications, many of which are still internet-facing, and the library itself is effectively abandoned — which is why CISA's advisory notes the product may be EoL/EoS and recommends discontinuing use.

The Vulnerability: CVE-2021-23758

• Vulnerability class: Deserialization of Untrusted Data (CWE-502)
• Impact: Unauthenticated remote code execution via arbitrary .NET classes
• Authentication required: None
• Attack vector: Network (crafted HTTP requests to AjaxPro handler endpoints)

The root cause is a classic .NET deserialization anti-pattern. AjaxPro's request handler accepts attacker-controlled JSON that can specify arbitrary .NET type information. Because the deserializer does not restrict which classes can be instantiated, an attacker can supply type discriminators referencing dangerous gadget classes available in the .NET runtime or application assemblies — the same class of weakness that has plagued BinaryFormatter, JavaScriptSerializer with type resolvers, and ObjectStateFormatter across the .NET ecosystem.

From the defender's perspective, the attack chain looks like this:

1. Reconnaissance: Attacker scans for ASP.NET applications exposing AjaxPro handlers — requests to paths such as /ajaxpro/*.ashx or handler URLs ending in .ashx that return AjaxPro-specific responses.
2. Delivery: Attacker sends a crafted POST request containing a malicious JSON payload with arbitrary .NET class references to the AjaxPro endpoint.
3. Deserialization & Execution: The server-side deserializer instantiates attacker-specified types. A suitable gadget chain achieves code execution in the context of the IIS worker process (w3wp.exe) — typically the application pool identity.
4. Post-exploitation: Web shell deployment (.aspx/.ashx files dropped into web root), credential access, and lateral movement follow — consistent with what we've seen in every in-the-wild .NET deserialization campaign.

Why This Is Exploitable at Scale

Three factors make this KEV addition particularly dangerous:

1. No authentication barrier. The vulnerable handlers are designed to be called by anonymous browsers.
2. Trivial discovery. AjaxPro endpoints are fingerprintable from the URL structure alone.
3. No supported fix path. With the library EoL/EoS, CISA's explicit guidance is to discontinue use and/or transition to a supported version — meaning many organizations cannot simply patch; they must re-architect or isolate.

Exploitation Status

• CISA KEV: Added 2026-08-26 — confirmed active exploitation in the wild
• Vendor status: Product likely EoL/EoS; no supported patch branch expected
• Required action (per CISA): Apply mitigations per vendor instructions; ensure compliance with BOD 26-04 prioritization guidance and CISA's Forensics Triage Requirements; discontinue use or transition to a supported version

Reference: CISA KEV Catalog — CVE-2021-23758

Detection & Response

The highest-fidelity detection surfaces for this exploitation pattern are: (1) the IIS worker process spawning unexpected child processes, (2) anomalous requests to AjaxPro handler endpoints in IIS/Proxy logs, and (3) web shell artifacts dropped into application directories. Prioritize the w3wp.exe child-process detection — it catches successful exploitation regardless of payload specifics, and legitimate w3wp.exe child processes are rare enough that this rule has real teeth.

Sigma Rules

---
title: IIS Worker Process Spawning Shell or Scripting Engine
description: Detects w3wp.exe spawning command shells, PowerShell, or scripting engines — a hallmark of post-exploitation following web application RCE such as the Ajax.NET Professional (AjaxPro) deserialization vulnerability (CVE-2021-23758).
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2021-23758
  - https://attack.mitre.org/techniques/T1190/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/08/28
status: experimental
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\w3wp.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cscript.exe'
      - '\wscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\whoami.exe'
      - '\net.exe'
      - '\nltest.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare legitimate application functionality that shells out (e.g., legacy reporting tools); baseline per application pool identity and app path
level: high
---
title: Web Shell File Dropped by IIS Worker Process
description: Detects the IIS worker process writing script-executable files into web content directories, consistent with web shell deployment following exploitation of a web application vulnerability such as CVE-2021-23758 (AjaxPro deserialization).
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2021-23758
  - https://attack.mitre.org/techniques/T1505.003/
author: Security Arsenal
date: 2026/08/28
status: experimental
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: windows
detection:
  selection_process:
    Image|endswith: '\w3wp.exe'
  selection_path:
    TargetFilename|contains:
      - '\inetpub\'
      - '\wwwroot\'
  selection_ext:
    TargetFilename|endswith:
      - '.aspx'
      - '.ashx'
      - '.asmx'
      - '.asp'
      - '.cshtml'
  condition: selection_process and selection_path and selection_ext
falsepositives:
  - Deployment pipelines publishing under the app pool identity; exclude known CI/CD service accounts and maintenance windows
level: high
---
title: Suspicious Requests to AjaxPro Handler Endpoints
description: Detects inbound HTTP requests targeting Ajax.NET Professional (AjaxPro) handler paths with POST bodies, a delivery pattern for the CVE-2021-23758 deserialization exploit. Tune against your proxy/WAF/IIS log source field mappings.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2021-23758
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/28
status: experimental
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri-stem|contains:
      - '/ajaxpro/'
    cs-method:
      - 'POST'
  condition: selection_uri
falsepositives:
  - Legitimate AjaxPro application traffic — pair with response-code analysis (500s followed by 200s), source-IP reputation, and volumetric anomalies; high-fidelity only where AjaxPro should not exist at all
level: medium

KQL — Microsoft Sentinel / Defender

This query hunts successful exploitation at the endpoint layer: any w3wp.exe process spawning shells or LOLBins. It works regardless of which web vulnerability was the entry point, so it doubles as a general web-RCE tripwire during your AjaxPro exposure review.

// Hunt: IIS worker process spawning suspicious child processes (post-exploitation of web RCE, e.g. CVE-2021-23758 / AjaxPro)
let SuspiciousChildren = dynamic(["cmd.exe","powershell.exe","pwsh.exe","cscript.exe","wscript.exe","mshta.exe","rundll32.exe","regsvr32.exe","certutil.exe","bitsadmin.exe","whoami.exe","net.exe","nltest.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ (SuspiciousChildren)
| project TimeGenerated, DeviceName, InitiatingProcessAccountName, InitiatingProcessCommandLine,
          FileName, ProcessCommandLine, SHA256, ReportId
| sort by TimeGenerated desc;

// Companion hunt: requests to AjaxPro handlers via ingested IIS/WAF/proxy logs (CEF/Syslog)
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where RequestURL contains "/ajaxpro/" or RequestURL endswith ".ashx"
| where RequestMethod == "POST"
| summarize RequestCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SourceIP, RequestURL, DestinationHostName, DeviceAction
| sort by RequestCount desc;

Velociraptor VQL

Use this artifact across your IIS estate to surface live post-exploitation behavior and to enumerate which servers even have AjaxPro present — the inventory half of this problem is often the harder one.

-- Hunt: w3wp.exe with suspicious child processes (post-exploitation triage for AjaxPro/CVE-2021-23758)
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)cmd|powershell|pwsh|cscript|wscript|mshta|rundll32|regsvr32|certutil|bitsadmin|whoami'
  AND Ppid IN (
      SELECT Pid FROM pslist() WHERE Name =~ '(?i)w3wp'
  )

-- Inventory: locate AjaxPro assemblies on web servers (exposure scoping)
SELECT FullPath, Size, Mtime
FROM glob(globs='C:\\inetpub\\**\\AjaxPro*.dll')

Remediation / Verification Script

Run this on every IIS server to enumerate AjaxPro exposure, check for exposed handler registrations, and audit for suspicious recently-written script files in web roots.

# AjaxPro (CVE-2021-23758) exposure assessment - run elevated on each IIS server
$report = [ordered]@{}

# 1. Find AjaxPro assemblies anywhere under inetpub and common app roots
$report['AjaxProDlls'] = Get-ChildItem -Path 'C:\inetpub','C:\Websites','D:\' -Recurse -Filter 'AjaxPro*.dll' -ErrorAction SilentlyContinue |
    Select-Object FullName, Length, LastWriteTime

# 2. Check web.config files for AjaxPro handler registrations
$report['HandlerRegistrations'] = Get-ChildItem -Path 'C:\inetpub' -Recurse -Filter 'web.config' -ErrorAction SilentlyContinue |
    Select-String -Pattern 'ajaxpro' -SimpleMatch -ErrorAction SilentlyContinue |
    Select-Object Path, LineNumber, Line

# 3. Audit for potential web shells: script files written in the last 30 days under web roots
$report['RecentScriptFiles'] = Get-ChildItem -Path 'C:\inetpub' -Recurse -Include *.aspx,*.ashx,*.asmx,*.asp,*.cshtml -ErrorAction SilentlyContinue |
    Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) } |
    Select-Object FullName, LastWriteTime, Length

# 4. List w3wp instances and their command lines (app pool context for scoping blast radius)
$report['WorkerProcesses'] = Get-CimInstance Win32_Process -Filter "Name='w3wp.exe'" |
    Select-Object ProcessId, CommandLine, CreationDate

$report | ConvertTo-Json -Depth 4 | Out-File "$env:TEMP\ajaxpro_exposure_$(hostname)_$(Get-Date -Format yyyyMMdd).json"
$report

Remediation

This is an EoL/EoS situation, so "apply the patch" is not the whole answer. Work this in order:

1. Immediate (within 24–48 hours):

• Inventory every IIS asset for AjaxPro presence using the script and VQL above. You cannot remediate what you haven't found — legacy vendor apps and inherited codebases are where this library hides.
• Isolate exposed applications behind a WAF rule blocking POST requests to /ajaxpro/*.ashx paths, or place the application behind VPN/allow-listing until remediated.
• Hunt before you remediate. Per CISA's Forensics Triage Requirements referenced in the KEV action guidance, collect triage data (process execution history, IIS logs, web-root file timelines) from exposed systems before rebuilding or taking them offline. Assume breach on any internet-facing AjaxPro host.

2. Short-term (per BOD 26-04 risk prioritization and your KEV SLA):

• Remove or disable the AjaxPro handler registrations in web.config if the AJAX functionality is unused. Verify application functionality in staging first.
• If the functionality is required, replace the library. Migrate AjaxPro-exposed methods to a supported framework pattern (ASP.NET Web API, minimal APIs, or controller-based endpoints with explicit model binding and no arbitrary type resolution). There is no supported in-place upgrade path for an abandoned library.
• Apply any vendor-specific mitigations if AjaxPro reached your environment via a third-party product — contact that vendor for their remediation guidance and supported version timeline.

3. Structural hardening (this quarter):

• Run application pools with least privilege — a dedicated, low-rights identity per app, no domain group memberships, no interactive logon. This doesn't stop RCE but meaningfully constrains post-exploitation.
• Enforce attack surface reduction rules blocking Office/script abuse and block w3wp.exe from spawning child processes where application functionality permits (Defender ASR or AppLocker).
• Egress filtering on web servers. Deny outbound internet from server VLANs by default; web shells and C2 die without egress.
• Add .NET deserialization to your secure SDLC review checklist. Any serializer configuration that accepts type discriminators from request bodies (JavaScriptSerializer with a resolver, TypeNameHandling other than None, etc.) should fail code review.

4. Deadlines: Federal agencies must remediate per the due date in the KEV catalog entry and in accordance with BOD 26-04. Private organizations should adopt the same date as their internal SLA — KEV-listed vulnerabilities under active exploitation are the canonical "drop everything" class.

Official references:

• CISA KEV Catalog — CVE-2021-23758
• CISA BOD 26-04 — Prioritizing Security Updates Based on Risk (linked in KEV entry Notes)
• CISA Forensics Triage Requirements (linked in KEV entry Notes)

Bottom Line

An abandoned .NET library from a previous era of web development is now an active intrusion vector. The defenders who get hurt here are the ones who don't know they have AjaxPro — start with inventory, hunt for w3wp.exe child processes and web shell artifacts on anything exposed, and treat removal (not patching) as the end state. If you find evidence of exploitation, escalate to full IR: deserialization RCE on a web server is rarely the attacker's final objective.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub