Exploited Known exploited (KEV) CVE-2021-23758

AjaxPro deserialization flaw (CVE-2021-23758) — how hard a "component" is to find once it is embedded in a product

Ajax.NET Professional Ajax.NET Professional Added to KEV Aug 26, 2026 Federal remediation due 2026-09-09

Ajax.NET Professional (AjaxPro), a .NET library, contains a deserialization of untrusted data vulnerability leading to remote code execution. CISA annotates it as an open-source component or third-party library that may be used inside different products, and notes the affected product may be end-of-life. It was added to KEV on 2026-08-26.

Key facts

  • CVE IDCVE-2021-23758
  • Affected (vendor / product)Ajax.NET Professional Ajax.NET Professional
  • CWECWE-502
  • ExploitationListed in CISA KEV (exploitation confirmed)
  • Remediation due2026-09-09 (U.S. federal civilian agencies, BOD 22-01)

Key points

  • The affected product is Ajax.NET Professional (AjaxPro); CWE-502, deserialization of untrusted data.
  • The catalog records that it could allow remote code execution via arbitrary .NET classes.
  • CISA's note places it in an open-source component or third-party library usable inside different products, and references the upstream fix commit.
  • The product may be end-of-life or end-of-service; discontinuing use or moving to a supported version is advised.
  • Added to KEV 2026-08-26 with a due date of 2026-09-09.
  • A component vulnerability never appears by name in an asset register, and the user can do nothing unless the bundling vendor ships a fix.

1Why deserialization turns into code execution

Deserialization converts data that was turned into a string or byte sequence for storage or transmission back into objects inside a program. The danger arises when external input can choose which class is reconstructed. Building an object runs the logic defined on that class, so if the attacker picks which class to create, they can trigger arbitrary behavior under the guise of restoring data. The catalog's phrase "via arbitrary .NET classes" points at exactly that structure.

2What being a "component" means

CISA's note explicitly places this vulnerability in an open-source component or third-party library that may be used inside different products. That is what makes it awkward to act on. What an organization tracks is normally the list of products it installed, not the libraries used inside those products.

If a vendor bundles AjaxPro, the name AjaxPro never appears in the asset register while the exposure is carried all the same.

3End of life, and the route a fix cannot travel

The catalog notes the product may be end-of-life or end-of-service and advises discontinuing use or moving to a supported version. The notes reference the upstream fix commit, but the fix existing upstream is not the same as it reaching a product that bundled the library. If the vendor doing the bundling issues no update, the user has no route of their own.

4Listed as a product, or as a component

Whether a vulnerability sits in a product or in a component that product uses changes how it is handled. This record is the latter, and CISA's note states explicitly that it belongs to an open-source component or third-party library.

A vulnerability in the product itselfA vulnerability in a component (library)
Listed in the asset register under the product nameThe component name never appears in the register
Fixed by applying the vendor's updateUnless the bundling vendor ships an update, the user can do nothing
Impact is confined to where the product is deployedIt spreads across separate products using the same component
Whether you are affected can be determinedIt cannot, without a register recording components

The note references the upstream fix commit, but a fix upstream and a fix reaching the products that bundle it are separate things. This is exactly where the software bill of materials becomes practical. Whether you can answer "are we affected" when a component itself lands on KEV is decided by the granularity of the register.

Why it matters

A vulnerability originating in a third-party library cannot be detected from an asset register of product names. Whether an organization can answer "are we affected?" when the component itself lands in KEV depends on the granularity of that register and on having a relationship in which suppliers will disclose what their products contain. Where the component is end-of-life, updating is not an option, so the response becomes the heavier decision of replacing or isolating the product.

FAQ

Why does deserialization become code execution?
Because if external input can choose which class is reconstructed, building the object runs logic defined on that class. Choosing the class lets an attacker trigger arbitrary behavior under the guise of restoring data.
How do we check whether we are affected?
A list of product names is not enough. The library may be used inside a product you installed, so you need vendor guidance or a software bill of materials that reaches the component level.
Is it safe if the fix exists upstream?
No. A fix existing upstream is not the same as it reaching a product that bundled the library. The vendor doing the bundling has to issue an update.

Sources (primary)

This article is an independent organization based on the U.S. official data below. Always verify the exact, latest details and applicability with the official and vendor sources.

#Security#CISA#KEV#Deserialization#.NET#Supply chain#SBOM
Disclaimer: This site independently summarizes and classifies information based on official data sources. Always verify the latest and accurate information with the official sources. Content on finance, health, legal, and security is information, not advice. This site is not an official website of the U.S. government.