Yes. CISA added CVE-2025-22457 to its Known Exploited Vulnerabilities catalogue on 4 April 2025, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Ivanti Connect Secure, Policy Secure, and ZTA Gateways contains a stack-based buffer overflow vulnerability that allows a remote unauthenticated attacker to achieve remote code execution.
What makes this a real exploitation case, not just a disclosed flaw?
CISA’s KEV listing is the practical signal that matters here: it means there is reliable evidence the issue is being used in active attacks, so this should be treated as an exploitation event, not a theoretical vulnerability. For edge appliances, that distinction changes urgency because exposure can exist before normal scanning, asset inventory, or patch windows catch up.
For readers tracking vulnerable remote-access infrastructure, the right starting point is the appliance itself, not the application layer behind it. A stack-based buffer overflow in an internet-facing gateway can become a direct path to code execution, which is why CISA’s catalogue and vendor advisories should be treated as primary reference points for version scope and remediation timing.
The question is also about trust boundary failure. When a perimeter access device is exploitable before authentication, the attacker does not need account credentials first; they may be able to turn the gateway into the initial foothold. That makes the issue materially different from an ordinary software bug inside a lower-exposure system.
How to confirm exposure and decide whether the appliance is in scope
Start by confirming whether any Ivanti Connect Secure, Policy Secure, or ZTA Gateway instance is reachable from untrusted networks and whether it is still within your supported deployment footprint. The operational question is not only “is the product present?” but also “is it exposed in a way that would let an unauthenticated remote attacker reach the vulnerable code path?”
For this class of issue, inventory quality matters as much as patch state. Shared appliances, forgotten test systems, partner-facing remote access endpoints, and standby nodes are common blind spots, especially when the product is treated as infrastructure rather than as a managed application with a defined owner and lifecycle.
A practical exposure check should also include whether the device has been modified, partially upgraded, or otherwise left in an inconsistent state. With internet-facing access infrastructure, the real-world risk often comes from drift between what the change system thinks is deployed and what is actually serving traffic.
What to do if patching has to wait
If immediate remediation is not possible, reduce exposure rather than assuming the device can remain “temporarily tolerated.” For a remotely exploitable edge appliance, that usually means shrinking who can reach it, tightening upstream controls, and treating any public reachability as a short-term exception that needs an expiry date and an owner.
If you need a focused runbook for that kind of response, the VPN Security Guide is the right internal reference for hardening, patching, and replacement decisions on appliance-style remote access platforms. The immediate objective is to preserve availability without pretending the device is safe simply because it is still functioning.
When patching must wait, the key decision is whether the service can be moved to a less exposed alternative or temporarily constrained enough that the attack surface meaningfully drops. If that is not possible, the exception should be treated as a business-risk decision, not a technical comfort decision.
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 SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Actively exploited edge-device flaws require rapid identification and remediation prioritization. |
| Recommendation — Prioritise and remediate KEV-listed appliance vulnerabilities through continuous vulnerability management. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | This CVE requires exposure verification and prompt tracking of a known exploited vulnerability. |
| SI-2 — Flaw Remediation | Active exploitation makes flaw remediation the core control response for this appliance vulnerability. | |
| SC-7 — Boundary Protection | The issue is an internet-facing gateway exposure problem, so boundary restriction directly reduces attack reachability. | |
| Recommendation — Monitor for the vulnerable Ivanti exposure and drive urgent remediation of identified instances. Apply vendor remediation quickly and document any temporary exception with expiry and ownership. Restrict external reachability to the gateway and tighten boundary protections until remediation is complete. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and recorded | Confirming whether Ivanti devices are exposed depends on knowing where the vulnerable assets exist. |
| Recommendation — Identify all Ivanti appliances and record which ones are exposed to untrusted networks. | ||
Practitioner Guidance
What to prioritise: Treat this as an emergency on any internet-facing Ivanti instance, then verify whether the appliance is directly reachable from untrusted networks before you spend time on broader remediation work.
What to verify: Confirm the exact product family, deployment role, and exposure path, then compare that against the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog entry rather than relying on internal vulnerability summaries alone.
Decision rule: If the device is public-facing or reachable by third parties, assume the blast radius is unacceptable until you have patched, constrained access, and checked for compromise; if it is truly isolated, the urgency drops but does not disappear.
Practitioner takeaway: For a KEV-listed edge appliance vulnerability, the right question is not whether a patch exists in theory, but whether the exposed device has already become an attacker-controlled entry point.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2025-22457 (Ivanti Connect Secure, Policy Secure, and ZTA Gateways Stack-Based Buffer Overflow)?
- CVE-2025-22457 (Ivanti Connect Secure, Policy Secure, and ZTA Gateways Stack-Based Buffer Overflow)
- How do you patch or mitigate CVE-2025-0282 (Ivanti Connect Secure, Policy Secure, and ZTA Gateways Stack-Based Buffer Overflow)?
- CVE-2025-0282 (Ivanti Connect Secure, Policy Secure, and ZTA Gateways Stack-Based Buffer Overflow)
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.
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