Yes. CISA added CVE-2025-0282 to its Known Exploited Vulnerabilities catalogue on 8 January 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 contain a stack-based buffer overflow which can lead to unauthenticated remote code execution.
What being “exploited in the wild” means for this Ivanti CVE
CISA’s KEV listing is the practical signal that matters most here: once a vulnerability is added, defenders should treat exposure as active, not hypothetical. For Ivanti Connect Secure, Policy Secure, and ZTA Gateways, the stack-based buffer overflow is not just a coding flaw, it is a route to unauthenticated remote code execution, so internet-facing appliances deserve immediate attention.
That changes the response posture. You are not deciding whether the issue is serious in abstract terms, you are deciding whether the affected appliances are reachable, whether they were exposed during the active exploitation window, and whether they can be patched or isolated quickly enough to reduce the chance of follow-on compromise.
If you need the source of truth for exploitation status and response timing, check the CISA Known Exploited Vulnerabilities Catalog and the vendor’s advisory rather than relying on secondary summaries. For a broader response pattern on exploited edge-device flaws, NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is the most direct operational reference.
How to confirm exposure and reduce blast radius
The first practical check is whether you still have any Ivanti Connect Secure, Policy Secure, or ZTA Gateway instances in production, test, partner, or disaster-recovery paths. Then verify whether they are internet reachable, whether they front critical access paths, and whether the vulnerable service is actually enabled in your deployment. External exposure matters more than abstract inventory here, because these appliances are often used as trust gateways.
Where the appliance is still needed, reduce blast radius before you wait for an ideal maintenance window. That means tightening management access, limiting who can reach the gateway, reviewing authentication dependencies, and treating the device as potentially compromised if it was exposed during the exploitation period. NHIMG’s VPN Security Guide and Remote Access Identity Guide both help frame the hardening and access-control side of that decision.
For prioritisation, combine exposure with exploitability. The NIST National Vulnerability Database gives the canonical CVE record, while CISA’s catalog tells you whether the issue has crossed into confirmed exploitation. That combination is more useful than severity alone when you are choosing which edge devices to take down first.
What to do when patching cannot happen immediately
If patching or full replacement must wait, focus on containment and surveillance, not reassurance. Restrict administrative reachability, enforce the narrowest possible access to the appliance, and watch for configuration drift, unexpected processes, new accounts, or changes to authentication and session behavior. On an edge appliance, a small initial foothold can become a durable internal pivot point.
Because the flaw can enable unauthenticated remote code execution, the next question is whether the device may already have been used as the entry point for a broader compromise. That is why teams should not stop at “we applied the fix later.” They should also review logs, session history, outbound connections, and any signs that the appliance was used to stage additional tooling or to harvest credentials after the initial exploit.
For response planning, the Ivanti Connect Secure exploitation 2024 case study is a useful reminder that edge-device exploitation often leads to credential theft and persistence, not just a one-off outage. If you need a control lens for what “good” looks like after remediation, NHIMG’s Vulnerability Management Guide is a good companion for verification, exception handling, and remediation tracking.
Risk and Threat Considerations
Internet-facing remote access appliances are high-value targets because they sit at the boundary between external users and internal trust. When active exploitation is confirmed, the risk is not limited to the vulnerable service itself, it extends to stolen sessions, captured credentials, hidden persistence, and lateral movement into internal systems that assumed the gateway was trustworthy.
Failure mechanism: A stack-based buffer overflow in a perimeter appliance can be triggered remotely and turned into code execution before normal authentication and authorization controls have a chance to help.
Impact: Attackers may gain a foothold on the gateway, pivot into internal networks, intercept or reuse access material, and create a compromise that survives the original vulnerability disclosure if credentials, sessions, or configurations are not reviewed.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Exploited edge-device flaws require rapid identification and remediation. |
| Recommendation — Prioritise exposed Ivanti appliances for immediate remediation and verification. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | Confirmed exploitation makes timely discovery and tracking of affected appliances essential. |
| IR-4 — Incident Handling | Active exploitation requires compromise assessment and containment beyond patching. | |
| Recommendation — Continuously identify vulnerable Ivanti instances and track remediation to closure. Open an incident workflow to contain, investigate, and eradicate possible compromise. | ||
| NIST Zero Trust (SP 800-207) | SA-2 — Architecture Requirements and Design | Remote access gateways are trust boundaries that should be explicitly constrained. |
| Recommendation — Reduce implicit trust in the gateway and limit access paths to only what is required. | ||
Practitioner Guidance
What to prioritise: Treat confirmed exploitation as an incident-response trigger, not just a patching task. If the appliance was reachable from the internet, prioritise exposure review, containment, and compromise assessment before normal maintenance scheduling.
What to verify: Confirm whether the gateway handled privileged remote access, whether any admin or service credentials traversed it, and whether logs show suspicious authentication patterns, unexpected outbound connections, or configuration changes around the KEV date.
Practitioner takeaway: For edge-device CVEs that are already in KEV, the safest assumption is that the appliance may have been used as a launch point, so remediation should include both repair and a targeted search for post-exploit activity.
Related resources from NHI Mgmt Group
- Is CVE-2025-22457 (Ivanti Connect Secure, Policy Secure, and ZTA Gateways Stack-Based Buffer Overflow) being exploited in the wild?
- 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)
- How do you patch or mitigate CVE-2025-22457 (Ivanti Connect Secure, Policy Secure, and ZTA Gateways Stack-Based Buffer Overflow)?