CISA KEV Catalog Update Adds Two Exploited Flaws and a Three-Day Deadline

CISA added two actively exploited vulnerabilities to its catalog on October 13, giving federal agencies only three days to address them. The CISA KEV catalog update covers CVE-2026-96951 in Microsoft Windows and CVE-2026-104935 in Ivanti Connect Secure. Both carry high severity scores, but their technical paths and operational risks differ sharply.

The short deadline is the first signal that this is more than a routine catalog change. CISA’s Known Exploited Vulnerabilities catalog, or KEV, tracks flaws supported by evidence of real-world exploitation. Its entries reflect observed attacker behavior, not just theoretical severity.

The deeper concern comes from the Ivanti case. Investigators found attackers chaining multiple zero-day flaws against a fully patched VPN appliance, reaching root privileges and removing evidence. The Windows vulnerability has broader product exposure, while the Ivanti intrusion shows why installing a patch cannot automatically clear a system of compromise.

What the CISA KEV Catalog Update Changed

CISA turned two newly disclosed vulnerabilities into immediate remediation priorities because attackers were already exploiting them.

The agency’s KEV additions identify CVE-2026-96951 as a Microsoft Windows command injection vulnerability. The second entry, CVE-2026-104935, is an authentication bypass affecting Ivanti Connect Secure.

CISA added both vulnerabilities on October 13, 2026. Federal Civilian Executive Branch agencies received an October 16 remediation deadline, leaving three calendar days between catalog entry and required action.

That timing matters. Vulnerability programs often prioritize work through severity ratings, asset value, exposure, maintenance windows, and available personnel. A three-day deadline compresses that entire process into an emergency response cycle.

CISA’s action requirements reference Binding Operational Directive 26-04, titled Prioritizing Security Updates Based on Risk. The directive applies to federal civilian agencies, but the catalog also serves as a public prioritization resource for private organizations.

The catalog does not claim that every affected system has been attacked. It establishes that CISA has accepted evidence showing successful exploitation somewhere in the wild. Organizations must still determine whether they own affected products, whether those assets were exposed, and whether compromise occurred.

The first vulnerability, CVE-2026-96951, affects Windows Shell. Command injection occurs when software fails to neutralize special command elements, allowing attacker-controlled input to alter what a system executes.

Microsoft’s CVE record gives the flaw a CVSS 3.1 base score of 8.8, classified as high severity. The vector describes a network-reachable attack with low complexity, no privileges required, and user interaction required. Successful exploitation can significantly affect confidentiality, integrity, and availability.

Affected products listed in the public record include several Windows 10, Windows 11, and Windows Server releases. Outlook.com also appears in the product data. Administrators should use Microsoft’s Windows security update as the authoritative guide for supported builds and fixes.

The second vulnerability, CVE-2026-104935, affects Ivanti Connect Secure, an enterprise remote-access gateway commonly positioned at a network boundary. Its authentication bypass lets a remote, unauthenticated attacker execute arbitrary commands on affected appliances.

Ivanti assigned the flaw a CVSS 3.1 score of 8.6, also high severity. Unlike the Windows flaw, its attack vector does not require user interaction. A vulnerable, reachable appliance can receive the malicious requests directly.

The Ivanti vulnerability affects releases before specified corrected versions in supported branches. Ivanti says Connect Secure 22.7R2.14 and earlier do not contain this particular vulnerability. That exception should not be interpreted as a general security endorsement for older software.

This CISA KEV catalog update therefore creates two distinct response tracks. Windows teams must distribute operating-system updates across a potentially large fleet. Network and incident-response teams must treat vulnerable Ivanti gateways as possible initial-access points.

The common fact is active exploitation. The response details cannot be reduced to one generic instruction to “patch immediately,” because the evidence required after patching differs between the two products.

A Three-Day Deadline Changes the Patching Decision

The primary tension is no longer severity versus convenience. It is rapid remediation versus the risk of overlooking an existing compromise.

The KEV catalog exists to help organizations distinguish vulnerabilities attackers use from the much larger pool of published CVEs. A high CVSS score describes technical severity under defined assumptions. KEV inclusion adds evidence that exploitation has moved beyond a hypothetical scenario.

That distinction is especially important for newly disclosed flaws. Exploit Prediction Scoring System data and broad telemetry can take time to mature. A KEV entry provides a stronger near-term signal when defenders must decide what to address first.

For federal civilian agencies, the October 16 deadline turns that signal into an operational requirement. Teams must identify affected assets, apply vendor mitigations, follow relevant forensic triage requirements, or discontinue use when adequate mitigations are unavailable.

Private organizations do not inherit the directive’s legal obligations. They do share the underlying exposure, however. The same Windows systems and remote-access gateways appear in corporate, healthcare, education, and critical-infrastructure environments.

The deadline also challenges patch programs built around monthly or quarterly maintenance windows. A routine approval path may involve lab validation, application-owner review, staged deployment, rollback preparation, and business signoff. Three days barely accommodates those tasks for a complex fleet.

That does not mean testing should disappear. A failed update can disrupt production, especially on identity-linked infrastructure or remote-access appliances. The practical response is to shorten the decision chain, isolate high-risk assets, and test the most representative configurations first.

Asset inventory becomes the first pressure point. A team cannot meet an emergency deadline if it lacks reliable records for operating-system versions, appliance builds, internet exposure, owners, and business dependencies.

Windows exposure can span endpoints and servers across multiple generations. The public CVE record lists Windows 10, Windows 11, and Windows Server products, including Server Core installations. Administrators need build-level confirmation instead of relying on product names alone.

Ivanti presents a different inventory problem. Connect Secure appliances often sit at the edge because they broker access between remote users and internal resources. Their placement makes them easy to reach and valuable after compromise.

An edge appliance also holds context that attackers want. It can process credentials, communicate with directory services, observe internal destinations, and provide a trusted position for reconnaissance. Those functions amplify the impact of a successful authentication bypass.

The forced response is therefore broader than deploying updates. Defenders must answer four questions quickly: Is the product present, is the installed version affected, was it exposed during the exploitation window, and does available evidence indicate compromise?

Teams that answer only the first two questions can produce a misleading sense of completion. Patching closes the known entry path. It does not remove credentials already stolen, undo lateral movement, or reconstruct logs an attacker erased.

The CISA KEV catalog update pressures security leaders to connect vulnerability management with incident response. Organizations that keep those functions separate can lose critical time while tickets move between teams.

A mature response assigns one owner to coordinate patching, exposure review, telemetry preservation, threat hunting, and executive communication. The owner does not need to perform every task, but someone must maintain a complete decision record.

That record should distinguish confirmed facts from assumptions. CISA confirms exploitation of both vulnerabilities. It does not establish that every exposed instance was targeted, identify every attacker, or describe the full scale of the campaigns.

Those gaps matter because urgency can encourage overstatement. “Actively exploited” is not equivalent to “mass exploited,” and KEV inclusion does not prove ransomware use. The catalog entries list known ransomware campaign use as unknown.

The Two Vulnerabilities Create Different Attack Paths

The Windows flaw expands the patching surface, while the Ivanti flaw concentrates risk at a privileged network gateway.

CVE-2026-96951 is formally titled the Windows Shell Security Feature Bypass Vulnerability. CISA describes it as a Microsoft Windows command injection flaw, reflecting the underlying CWE-77 weakness.

The published attack vector indicates remote reachability, low attack complexity, no required privileges, and required user interaction. Those characteristics suggest that exploitation depends on a target taking some action with attacker-supplied content.

Public technical details remain limited. Defenders should avoid inferring an exact delivery mechanism from the vulnerability class alone. The official record establishes the affected component and impact, but not a complete public playbook for every observed attack.

Network detection documentation provides one useful lead. Cisco’s Snort rule description says it looks for Windows settings files that reference Windows Terminal and may not properly indicate their web origin. That behavior can lead to arbitrary command execution after user interaction.

Detection logic is not a substitute for Microsoft’s guidance. A network signature can miss encrypted traffic, alternate delivery paths, modified payloads, or activity outside its inspection point. It should supplement patch verification and endpoint telemetry.

The Windows response should begin with build-level inventory. Administrators need to compare each installed version with the corrected builds in Microsoft’s advisory, then confirm that updates installed successfully.

That process must include systems that do not follow normal consumer update channels. Servers managed through Windows Server Update Services, Microsoft Intune, third-party tools, images, or offline procedures can show different deployment timing.

Legacy Windows versions deserve special attention because operational dependencies often delay updates. A vulnerable server that supports an older application can remain exposed after the main endpoint fleet reaches compliance.

Where immediate updating is impossible, defenders should apply Microsoft’s documented mitigations and reduce exposure. They should also monitor for suspicious child processes, unusual command execution, and artifacts associated with attacker-delivered settings files.

CVE-2026-104935 presents a more direct network threat. Its CVE record describes authentication bypass by spoofing in Ivanti Connect Secure before version 25.1.3.0.

A remote attacker needs no valid account and no user interaction. The flaw permits arbitrary command execution on the appliance, creating a direct path from the internet to software trusted by the internal network.

Ivanti’s affected-version information requires careful reading. The record identifies corrected releases across several branches, including 25.1.3.0, 25.1.3.1, and 22.8R2.5. Version 25.1.1.2 also appears as a corrected build in public reporting tied to the vendor guidance.

Administrators should confirm their exact branch against the current Ivanti security advisory. They should not select a target version from a secondary summary when the vendor’s instructions are available.

The vulnerability’s importance becomes clearer when placed in the observed attack chain. Security firm Volexity found a threat actor exploiting three previously unknown weaknesses against Connect Secure.

The first weakness let an unauthenticated request reach a protected CGI handler. A CGI handler is server-side software that processes web requests and can invoke system functions.

The second weakness created a brief file-write and execution opportunity. The attacker uploaded a Perl script disguised with a ZIP extension, then raced the appliance’s validation and deletion process.

A separate privilege-escalation flaw raised that code execution to root. Root is the highest administrative privilege on the appliance’s underlying Linux environment.

This distinction is important. CVE-2026-104935 tracks the authentication bypass and remote-code-execution portions of the chain. Volexity said Ivanti was still preparing a fix for the separate privilege-escalation vulnerability at publication time.

The observed chain therefore exceeded the effect of one isolated bug. It combined access-control failure, temporary file execution, and privileged service behavior to reach full control of a fully patched appliance.

That is the central tradeoff in this story. Organizations must move quickly on a known fix, but they cannot treat the fix as a complete account of the attacker’s capabilities.

Ivanti Shows Why Patching Is Not Forensic Clearance

A patched appliance can still represent an unresolved incident when attackers operated before the update and erased local evidence.

Volexity began investigating suspicious activity on October 5. The firm found exploitation dating back to October 3 against Connect Secure 22.8R2.4, which was fully patched at the time.

Its detailed exploit-chain analysis attributes the activity to a previously undocumented threat actor tracked as UTA0576. That label identifies a cluster of observed behavior, not a confirmed real-world identity.

The threat actor used the appliance for reconnaissance, credential theft, data collection, and preparation for possible lateral movement. Investigators found activity targeting directory credentials and secrets.

The attacker extracted credentials stored on the VPN appliance, including domain credentials used for LDAP. LDAP, or Lightweight Directory Access Protocol, lets systems query and manage directory information.

Investigators also found attempts to obtain Local Administrator Password Solution credentials and BitLocker recovery keys. Those secrets can provide access to endpoints or encrypted systems beyond the original appliance.

The actor searched authentication logs, collected appliance configuration data, and conducted internal DNS reconnaissance. It also used password spraying, which tests a small number of passwords against many accounts.

That activity demonstrates why an edge-device compromise can become an enterprise incident. The appliance was not merely a single vulnerable box. It provided credentials, network visibility, and a launch point for deeper access.

Volexity assessed with high confidence that the attacker’s actions prepared for lateral movement and a broader network compromise. The operation was disrupted before investigators could determine the actor’s ultimate objective.

The actor also used anti-forensic techniques. It modified selected Ivanti debug logs and Linux audit logs, removed temporary files, and restored altered in-memory state after gaining root access.

No persistent web shell was necessary. The attacker repeatedly used the exploit channel to send commands and receive results over HTTPS, reducing the need to leave a conventional backdoor on disk.

The technique complicates detection. Many incident-response workflows begin by searching a disk image for malware, modified binaries, suspicious startup entries, or web shells. A mostly memory-resident chain can leave less durable evidence.

Ivanti provides an Integrity Checker Tool that looks for unexpected changes on disk. Volexity found that the observed chain altered memory and restored relevant configuration data, allowing it to avoid detection by that tool.

This does not make the Integrity Checker useless. It means a clean result cannot independently prove that an appliance was never compromised by this chain.

Organizations with an affected, internet-exposed appliance need a stronger decision process. They should preserve evidence before reimaging when practical, examine network telemetry, review authentication activity, and look for lateral movement originating from the gateway.

Memory evidence can be especially valuable because the attacker’s code and modifications may exist only while the appliance is running. Rebooting or replacing the device can destroy that volatile evidence.

Operational urgency can conflict with evidence preservation. A security team may want to disconnect and rebuild immediately, while incident responders need memory, logs, and surrounding telemetry.

The correct balance depends on active risk. If ongoing compromise is suspected, containment comes first. Teams should still record the system state and collect the best available evidence without unnecessarily extending attacker access.

Credential response is equally important. If an affected gateway stored or handled directory credentials, administrators should identify those accounts and rotate relevant secrets. They should not assume the patch protects credentials already collected.

BitLocker recovery data, local administrator passwords, service-account credentials, and VPN configuration secrets deserve separate review. Rotation priorities should reflect which secrets the appliance could access and what telemetry shows.

The risk extends to trusted connections. A compromised gateway can make malicious internal traffic appear to originate from legitimate infrastructure. Detection teams should review activity sourced from the appliance, not just inbound requests directed toward it.

Volexity recommended monitoring for unusually large request volumes involving the public welcome CGI path. It also highlighted mismatches between the visible URL and the X-DSCGI-PATH header.

Those indicators are useful but incomplete. Once technical details become public, attackers often adjust paths, request patterns, infrastructure, or post-exploitation tools. Defenders should combine specific indicators with behavioral analysis.

The skeptical point is straightforward: the public investigation documents one victim and one observed cluster. It provides strong evidence about the mechanism, but it does not reveal the campaign’s full scale.

Ivanti said it knew of exploitation affecting a limited number of customers at disclosure. That statement should be treated as the vendor’s current visibility, not a definitive upper bound on compromised systems.

Unknown exposure is especially significant when logging is incomplete or attackers erase evidence. Absence of an alert cannot establish absence of exploitation.

What the Public Record Still Does Not Show

The two KEV entries confirm exploitation, but they leave attribution, scale, delivery, and complete victim impact unresolved.

CISA has not publicly identified the attacker exploiting CVE-2026-96951. The available Windows record also does not provide a complete description of the observed campaigns.

Microsoft’s vector indicates user interaction, which separates the Windows flaw from the unauthenticated Ivanti gateway attack. However, defenders still lack a fully public account of the lure, delivery channel, and post-exploitation sequence.

That gap limits campaign-specific detection. Security teams can deploy the update and monitor relevant Windows behavior, but they should avoid presenting one guessed delivery mechanism as confirmed.

The Ivanti case offers far more technical visibility because Volexity reconstructed the chain from memory, disk evidence, and core dumps. Even there, important questions remain open.

Volexity assessed with low confidence that UTA0576 had criminal motivations based on the observed target. Low-confidence attribution means the available evidence supports the assessment only weakly.

The firm also assessed with medium confidence that the actor used large language models during exploit development or post-exploitation. It based that judgment on tailored scripts, hardcoded credentials, repeated command-channel use, and the chain’s complexity.

That assessment is not direct proof of AI use. Similar operational patterns can result from human development, established private tooling, or iterative manual work. The claim should not become the headline of the incident without additional evidence.

A separate uncertainty concerns the privilege-escalation component. Ivanti patched the authentication bypass and remote-code-execution path tracked as CVE-2026-104935. Volexity said the additional privilege-escalation fix would arrive later.

The remaining flaw does not mean the patched authentication bypass stays exploitable. It does mean defenders should follow subsequent vendor releases rather than treating the October 13 update as the final security event.

Version status also needs precision. The CVE record says 22.7R2.14 and earlier do not contain CVE-2026-104935. Older branches can still contain unrelated vulnerabilities, lack current support, or fall outside recommended deployment paths.

Organizations should not downgrade to an older “unaffected” release as an improvised mitigation. They should follow supported upgrade instructions and confirm the vendor’s latest position.

The ransomware field provides another potential source of confusion. CISA lists known ransomware campaign use as unknown for both entries. That value means the catalog has not established a ransomware connection, not that ransomware operators will ignore the flaws.

Attackers frequently reuse publicly disclosed edge-device vulnerabilities after patches become available. Public technical analysis can accelerate defensive work and offensive replication at the same time.

Proof-of-concept availability is also an incomplete measure. CISA’s evidence of active exploitation already establishes real-world risk even if no reliable public exploit appears in common repositories.

For executive communication, teams should separate four levels of evidence. The flaws exist, exploitation has occurred, one Ivanti attack chain is technically documented, and broader campaign scope remains uncertain.

That framing supports urgency without sensationalism. It also prevents leaders from assuming every affected system is breached or, conversely, that limited public victim reporting means exposure is safe.

The CISA KEV catalog update is most valuable as a decision signal. It tells defenders where verified exploitation has overtaken theoretical risk. It does not replace asset-specific investigation.

Three Signals Defenders Should Watch Next

The next phase depends on patch coverage, forensic findings, and vendor updates addressing the rest of the Ivanti chain.

The first signal is verified remediation by the October 16 deadline. Federal agencies must demonstrate that affected assets received the required treatment under BOD 26-04.

Private organizations should use the same date as an urgency benchmark, even when their operational constraints differ. The useful metric is not the number of update tickets created. It is the percentage of affected, reachable systems that are patched, mitigated, isolated, or removed.

A fast patch rate would reduce the window for attackers to reuse these paths. Persistent exposure after public disclosure would strengthen the case that KEV deadlines remain difficult to execute across real environments.

The second signal is the emergence of additional forensic findings. Investigators may identify more Ivanti victims, new indicators, alternate request paths, or downstream activity involving stolen credentials.

Evidence of broader targeting would strengthen the judgment that affected appliances require incident-response treatment, not only vulnerability remediation. A lack of new public cases would not disprove additional compromise, especially where telemetry is weak.

Windows campaign details also belong under this signal. New reporting could clarify how attackers deliver malicious content, which sectors they target, and what commands execute after the security bypass.

Organizations should update detections as those details emerge. They should retain enough endpoint and network telemetry to search backward when new indicators become available.

The third signal is Ivanti’s follow-up release for the separate privilege-escalation vulnerability. That update will show when the vendor considers the entire publicly documented chain addressed across supported branches.

Administrators should track the advisory rather than assuming their work ended with the first fixed build. Each new release should trigger version review, testing, deployment planning, and confirmation that older appliances remain on supported paths.

These three signals also provide a practical action order. Confirm current exposure first, investigate activity during the vulnerable period second, and keep monitoring vendor guidance third.

For Windows, verify corrected builds across endpoints and servers, then review suspicious Shell and Terminal-related execution. Preserve relevant endpoint telemetry before normal retention windows remove it.

For Ivanti, confirm the exact appliance branch, apply the supported update, and review internet exposure during the known exploitation window. Investigate unexpected activity originating from the gateway and rotate accessible credentials when compromise cannot be excluded.

Do not use a clean integrity check as the sole basis for closure. The documented attack changed memory, erased logs, and restored state specifically to reduce visible traces.

The CISA KEV catalog update delivers a narrow message with broad consequences: exploitation has already crossed from possibility into observation. The remaining question is whether each organization can prove its own systems were fixed before attackers reached them.

Security teams should document that answer now. Which affected assets were exposed, what evidence was preserved, which credentials were reachable, and who has authority to close the incident? A completed patch deployment is one milestone. Defensible assurance requires a record showing that exposure, exploitation, and downstream access were each examined.