How do you patch or mitigate CVE-2026-104935 (Ivanti Connect Secure Authentication Bypass by Spoofing)?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

CISA's required action for CVE-2026-104935 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.

Patch or mitigation for this CVE starts with confirming whether your Ivanti Connect Secure estate is internet exposed and then applying the vendor's mitigations exactly as instructed. Because CISA has already directed organisations to follow vendor guidance under BOD 26-04, this is not a “wait and see” issue, it is a priority patching and exposure-management problem for any reachable appliance.

When patching is not immediately possible, the practical question becomes whether the appliance can be kept in service without violating the required mitigations. If the product cannot be made compliant, the safer operational choice is to discontinue use until the vendor-supported fix or mitigation path is available, especially for any instance with direct external exposure.

There is also a forensics question, not just a patch question. For authentication-bypass flaws, you should assume an attacker may have reached management or user-facing functions before the fix, then validate logs, sessions and related access events for signs of prior misuse. If you find evidence of suspicious access, treat credential rotation, session invalidation and follow-on account review as part of the response, not as optional cleanup.

How to Apply the Vendor Mitigation Without Creating False Confidence

The safest way to approach this CVE is to treat the vendor instruction set as the source of truth and make the mitigation decision asset by asset, not by policy abstraction. Internet exposure, device role, and whether the appliance is still supporting business-critical remote access all affect how quickly you can enforce the required action.

If the vendor mitigation can be applied cleanly, verify that the appliance is back in a known-good state and that any compensating control really reduces exposure rather than merely slowing attacker access. A mitigation is only useful if it is durable, observable, and compatible with the product's current deployment model.

For teams managing remote access gateways, the broader lesson is that appliance hardening and patching have to be tied to inventory, ownership, and exposure status. A device that is forgotten, duplicated in a DR segment, or exempted because it is “legacy but stable” is exactly the sort of asset that turns an authentication bypass into an incident.

Use the VPN Security Guide to align appliance patching, hardening and replacement planning with the operational realities of edge devices and VPN exposure.

What to Do If Patching Must Wait

If the appliance cannot be patched immediately, reduce reachable surface area first. That means removing unnecessary internet exposure, constraining administrative paths, and reviewing whether the service can be temporarily isolated or retired from direct external access while the remediation window is open.

Do not treat a temporary exception as a safe long-term control. The key decision is whether you can reduce exposure enough to make the residual risk acceptable until the fix is deployed, or whether the correct answer is to take the product out of service.

For organisations that rely heavily on remote access, this is where replacement planning matters. If the control can only be maintained by continuously deferring remediation, then the environment is signalling that the product has become an operational dependency with unacceptable security cost.

Use Remote Access Identity Guide to evaluate whether stronger identity controls and lower-trust access patterns can reduce dependence on exposed gateway appliances.

How to Check for Earlier Compromise After an Authentication Bypass

An authentication bypass creates a realistic chance that an attacker got in before defenders noticed the weakness. That makes post-fix validation essential: review authentication logs, administrative actions, session history, configuration changes and any unusual access from unfamiliar sources or at unusual times.

Focus on what the appliance could expose if it were used as an entry point. For remote-access devices, that often includes user credentials, session artefacts, internal routing knowledge and pathways to adjacent systems, so the investigation should extend beyond the appliance itself.

Use the Ivanti Connect Secure exploitation 2024 write-up as a reminder that these devices have previously been used to harvest credentials and support follow-on access.

Where your review suggests access may have extended beyond the appliance, the investigation should branch into account review and session invalidation. That is particularly important when the gateway is tied to privileged users, service accounts or downstream administrative workflows.

Risk and Threat Considerations

Authentication bypass on an externally reachable security appliance is high risk because it can convert a perimeter control into an unauthenticated entry point. The consequence is not just unauthorized login, but possible lateral movement, session abuse, and exposure of the remote-access trust boundary.

Failure mechanism: An attacker can exploit the bypass to reach functions that were supposed to require valid authentication, then use that foothold to access sessions, pivot into internal services, or observe sensitive configuration and identity material.

Impact: The appliance may become a launch point for broader compromise, including account takeover, credential theft, and internal network access, especially if the device is internet exposed and widely trusted by users or administrators.

Standards & Framework Alignment

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

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	CVE remediation depends on timely identification and treatment of exposed assets.
Recommendation — Prioritise and remediate the affected appliances using risk-based vulnerability management.
NIST CSF 2.0	PR.IP-12 — Vulnerability Management	The question is about applying mitigations and patching an exploitable vulnerability.
Recommendation — Track the CVE through a formal vulnerability management process and verify remediation.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This asks how to patch or mitigate a specific product flaw.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and post-fix verification require scanning and monitoring.
	IR-4 — Incident Handling	Authentication bypasses require compromise checks and response if abuse is detected.
Recommendation — Apply vendor-supported flaw remediation and validate that the fix is in place. Scan exposed appliances and validate that the vulnerability is no longer present. Investigate for prior compromise and escalate to incident response if abuse is found.

Practitioner Guidance

What to verify: Confirm whether every deployed appliance is covered by the vendor mitigation path, whether the device is internet exposed, and whether there is a documented exception only for the shortest possible period. If you cannot verify those three things, you do not yet have control over the exposure.

Decision rule: If the appliance cannot be brought into compliance with the required mitigation, retire it or remove external exposure rather than relying on compensating controls that are hard to observe and even harder to prove.

Practitioner takeaway: For an authentication bypass on an edge device, patching is only half the job, the real test is whether you can prove the device is no longer a viable unauthenticated entry point after remediation.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org