Severity Daily

IT and AI security incidents, checked against the primary source

Tag: agentic AI

  • AjaxPro shipped a deserialization fix in November 2021. The CVE now on a federal clock still says no fixed version exists.

    AjaxPro shipped a deserialization fix in November 2021. The CVE now on a federal clock still says no fixed version exists.

    What happened

    CISA added CVE-2021-23758 to the Known Exploited Vulnerabilities catalog on August 26, 2026. NVD’s copy of the record carries CISA’s own fields verbatim: a cisaExploitAdd of 2026-08-26, a cisaActionDue of 2026-09-09, and a cisaVulnerabilityName of “Ajax.NET Professional Deserialization of Untrusted Data Vulnerability.” Federal civilian agencies have until September 9, 2026. NVD last modified the record on August 27, 2026 and marks its status “Analyzed.”

    What changed on August 26 is the federal obligation, not the bug: the vulnerability was published on December 3, 2021. What makes the addition worth reading is that the record an agency will consult to satisfy the deadline does not agree with itself about whether a patched version exists.

    AjaxPro, or Ajax.NET Professional, is one of the oldest AJAX frameworks for ASP.NET, supporting .NET versions back to 1.1. CVE-2021-23758 is a deserialization flaw in it. The CVE record, assigned by Snyk, describes it in one sentence: “All versions of package ajaxpro.2 are vulnerable to Deserialization of Untrusted Data due to the possibility of deserialization of arbitrary .NET classes, which can be abused to gain remote code execution.” The credited reporter is Hans-Martin Münch of MOGWAI LABS, with a disclosure date of November 21, 2021.

    Three things in the public record do not line up.

    Whether a fix exists. Snyk’s advisory for this CVE states flatly that there is no fixed version for AjaxPro.2, and the CVE record’s affected-version array says the same thing structurally: version 0, status affected, no upper bound. The GitHub Advisory Database entry for the same CVE, GHSA-6r7c-6w96-8pvw, says the opposite. It lists the affected range as 21.11.29 and earlier and names a patched version: 21.11.29.1. That entry was published on December 5, 2021 and last updated on February 3, 2026.

    Whether the vendor acted. The vendor’s own release history supports GitHub’s reading. Release v21.11.22.1, dated November 22, 2021, is described in its notes as having “Changed behavior of types deserialization to deny.” Release v21.11.29.1, dated November 29, 2021, is described as having “Fixed missing custom deserialization filter for converters” and having removed a default converter. The commit that introduced the allow-and-deny list for deserializable types, “added allowed customized types,” is dated October 27, 2021 — and it is cited as a reference on the CVE record itself. The maintainer shipped a deserialization control before the CVE was published, and the CVE links to that commit while still describing every version as vulnerable.

    Which package this is. The CVE names the package ajaxpro.2. On NuGet, the package published under that identifier has exactly two versions, the newer of them 6.10.6.2, published on July 5, 2016, with 129,890 downloads. It never received the 2021 changes and it displays no vulnerability banner. The maintained package is published under a different identifier, AjaxNetProfessional, whose latest version is 24.10.10.1, published on October 10, 2024, with roughly 33,900 downloads across all versions. That is the package GitHub’s advisory maps the CVE to. NuGet does flag several 2021-era AjaxNetProfessional versions as carrying critical- or high-severity vulnerabilities. It flags nothing on the package whose name appears in the CVE.

    The scores diverge too. NVD carries two CVSS v3.1 entries: a primary from [email protected] at 9.8 critical, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and a secondary from [email protected] at 8.1 high, vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Identical but for attack complexity. GitHub carries the 9.8 figure.

    The exploitation evidence is a single vendor’s research. Cisco Talos published a report on August 20, 2026 on an actor it tracks as UAT-10147, which it characterizes as a “Chinese-speaking cybercrime group” and, with moderate-to-high confidence, as representing “an emerging class of financially motivated intrusion operators leveraging agentic AI systems.” Talos describes “AI-generated operational playbooks, exploit automation scripts, and troubleshooting logic supporting real-world intrusions.” CVE-2021-23758 is one of four initial-access vulnerabilities named, alongside CVE-2022-27925 in Zimbra, CVE-2019-18935 in Telerik UI for ASP.NET AJAX, and CVE-2021-29441 and CVE-2021-29442 in Nacos. Talos reports a target list of approximately 170,000 URLs and victims in Brazil, Bolivia, China, Canada, and Vietnam across government, education, media, technology, and gaming. A target list is not a victim count, and the report does not put a number on successful compromises.

    Why it matters

    CISA’s required action for this entry is the current boilerplate: “Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk guidance and CISA’s ‘Forensics Triage Requirements.’ Follow applicable BOD 26-04 guidance for cloud services or discontinue use if mitigations are unavailable.” We have written before about how little that sentence distinguishes one entry from another.

    Here it distinguishes a great deal, because the clause that fires depends on which database the agency read. “Apply mitigations in accordance with vendor instructions” and “discontinue use if mitigations are unavailable” are very different orders. An agency that resolves the CVE through GitHub’s advisory sees a patched version, upgrades, and closes the ticket. An agency that resolves it through the CNA’s own advisory — the authority that assigned the identifier — sees that no fixed version exists, and the required action tells it to rip the framework out of whatever application depends on it, inside 14 days. The record does not adjudicate between those two outcomes. It supports both.

    The package-identity split compounds it, in a way specific to how this work is actually done. Nobody reads CVE prose to find affected assets; they match package identifiers against a bill of materials. A scanner keyed to the CVE’s identifier looks for ajaxpro.2 and finds a package frozen in 2016 that the registry flags with nothing — while the CVE naming it says every version is vulnerable. The two most likely automated answers to “am I affected” are wrong in opposite directions.

    None of this is exotic. It is the ordinary consequence of a record written once in 2021, describing a package by an identifier that was already stale, and never revised as the vendor fixed the flaw and moved distribution elsewhere. For five years that cost nothing. BOD 26-04 derives federal remediation deadlines partly from KEV listing, which converts a dormant record into a dated obligation. Its defects become operational on the day it is added, and are inherited exactly as written.

    The exploitation evidence carries a second-order point. On Talos’s account, a 2021 flaw in an obscure AJAX framework is being worked at scale in 2026 because building an exploitation workflow for an obscure target no longer costs an operator much. If that holds, the population of old, low-profile CVEs worth weaponizing gets larger, and more of them will arrive on federal clocks carrying record defects nobody has examined in years.

    What to do

    Search your inventory for both identifiers, not one: AjaxPro.2 and AjaxNetProfessional. Search the assembly name too — the October 2021 commit renamed it from AjaxPro to AjaxPro.2 — and the vendored copies a framework of this vintage leaves in bin directories rather than a package manifest.

    If you are on AjaxNetProfessional, GitHub’s advisory puts the patched version at 21.11.29.1; the current release is 24.10.10.1, published October 10, 2024. Move to the current release rather than to the minimum that clears the advisory.

    If you are on the AjaxPro.2 NuGet package, treat the absence of a registry warning as meaningless. That package has not been updated since July 5, 2016 and cannot contain the November 2021 deserialization changes. Migrate to the maintained package or drop the dependency.

    Whichever package you are on, set the deserialization allow list. The vendor’s configuration exposes a jsonDeserializationCustomTypes setting with allow and deny lists governing which classes can be instantiated during deserialization; the default posture was changed to deny in November 2021. Confirm the setting is present and restrictive in your own configuration rather than assuming the version’s default.

    Check exposure as well as version. This is a framework endpoint reachable without authentication, so the question is whether an AjaxPro handler is routable from the internet, not only whether the assembly is current. Federal agencies working the September 9 deadline should also document which advisory they relied on: given that the CNA record says no fix exists, an assessor reading that same record could reasonably ask why the framework was upgraded rather than discontinued.

    Sourcing note

    KEV dates come from NVD’s record for CVE-2021-23758, which republishes CISA’s cisaExploitAdd, cisaActionDue, cisaVulnerabilityName and cisaRequiredAction fields. CISA’s own catalog pages return 403 to automated fetching, so the catalog was not read directly; the values here are NIST’s republication, cross-checked against a third-party KEV mirror. Affected-version data, CNA identity, and CVSS metrics were read from the CVE Program’s API record and from NVD. The competing patched-version claim comes from the GitHub Advisory Database entry GHSA-6r7c-6w96-8pvw and the no-fix claim from Snyk’s advisory SNYK-DOTNET-AJAXPRO2-1925971. Release dates, release-note wording, and the commit message were read from the vendor’s GitHub repository. Package version and download figures were read from NuGet’s package pages. Exploitation is single-sourced to Cisco Talos’s August 20, 2026 report on UAT-10147; we found no independent corroboration, and the 170,000 figure is Talos’s count of a target list, not of victims. The Packet Storm exploit file referenced by the CVE record could not be retrieved — the host disallows automated fetching — so its contents are not characterized here beyond the title NVD carries.

    Unresolved: whether Snyk intends to revise an advisory that says no fix exists for a package the vendor stopped shipping in 2016, and whether NVD will reconcile a description that calls all versions vulnerable with the fix commit its own reference list links to. The attack-complexity split behind the 9.8 and 8.1 scores is also unexplained publicly.