Is CVE-2025-20281 (Cisco Identity Services Engine Injection) being exploited in the wild?

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

Yes. CISA added CVE-2025-20281 to its Known Exploited Vulnerabilities catalogue on 28 July 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Cisco Identity Services Engine contains an injection vulnerability in a specific API of Cisco ISE and Cisco ISE-PIC due to insufficient validation of user-supplied input allowing an attacker to exploit this vulnerability by submitting a crafted API request.

What the wild-exploitation answer means for Cisco ISE exposure

For a question like this, the practical issue is not just whether a CVE exists, but whether the vulnerable API is reachable in your environment and whether the affected Cisco ISE or ISE-PIC deployment is exposed to untrusted request paths. Because the issue is an injection flaw, validation boundaries and request handling are the key control points, not just version awareness. The safest starting point is the vendor advisory and the CISA KEV catalogue for authoritative scope and remediation detail.

When a vulnerability is already in KEV, treat exposure as an operational priority rather than a theoretical concern. Even if you have not seen obvious abuse, you should assume the attack window is active until you have confirmed whether the affected interface is present, reachable, and properly constrained. That is especially true for administrative or authentication-adjacent services where a crafted request can change server-side behavior.

One useful way to frame the issue is to separate product exposure from exploitability. A system can be installed yet unreachable, or reachable but protected by network controls, segmentation, or compensating restrictions. For this class of flaw, the material question is whether an attacker can submit the crafted API request path described in the advisory and whether that path leads to meaningful server-side processing. If yes, the exposure is real even before you confirm exploitation.

How to assess whether you are actually exposed

Start by inventorying where Cisco ISE and Cisco ISE-PIC are deployed, what management or API surfaces are exposed, and whether those surfaces are reachable from any untrusted network segment. Confirm whether the specific API named by Cisco is present in your build and whether it is reachable from locations that should never be able to send arbitrary requests.

Then validate the control plane around the service. If the API is only meant for trusted administration, check whether access is limited to approved administrative hosts, whether any reverse proxy or gateway rules are narrowing the attack surface, and whether there is telemetry for abnormal request patterns. For an exploited-in-the-wild issue, logs and network traces matter as much as patch status because they help separate theoretical exposure from likely compromise.

When patching or mitigation cannot happen immediately, reduce reachability first. Remove any unnecessary external exposure, tighten access paths, and watch for requests that do not match normal administrative behavior. If the service must remain available, constrain who can talk to it and increase monitoring around the API route implicated by the vulnerability.

What to do if patching has to wait

If you cannot remediate immediately, the decision should be driven by blast radius. A vulnerable identity or access platform often sits close to authentication flows, policy enforcement, and user or device onboarding, so compromise can have disproportionate downstream impact. Temporary controls should therefore focus on making the vulnerable interface hard to reach and easy to observe, not on hoping the flaw is never touched.

Check for signs that the service has already been probed or abused: unusual API requests, malformed input, spikes in 4xx or 5xx responses tied to the relevant endpoint, unexpected administrative activity, or changes that do not match your change calendar. If you find suspicious activity, preserve logs before remediation so you can answer whether the issue was merely scanned or actually exploited.

If there is evidence of compromise, treat the response as more than a software patch event. Review whether the platform could have exposed session material, tokens, administrative credentials, or policy data, and rotate or reissue anything that may have been reachable through the affected service boundary. The exact rotation scope depends on what the platform exposed in your environment, but the principle is simple: assume trust relationships may have been abused until proven otherwise.

Risk and Threat Considerations

This vulnerability is high-risk because active exploitation means attackers are no longer just testing an edge case, they are already using it to reach a service that often sits near identity enforcement and administrative control. Injection flaws in management or API surfaces can be attractive because they may let an attacker influence backend behavior with a single crafted request.

Failure mechanism: Insufficient validation of user-supplied input allows a crafted API request to alter server-side processing. If the vulnerable endpoint is reachable, the attacker does not need privileged local access, only a request path that the service will accept and process.

Impact: The likely consequences include unauthorized access, service abuse, policy manipulation, and possible compromise of data or credentials handled by the platform. In an identity-centric system, the downstream effect can extend beyond the appliance itself because trust decisions, authentication flows, and administrative functions may depend on it.

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	Active exploitation makes exposure tracking and rapid remediation central to this Cisco ISE flaw.
Recommendation — Prioritize and remediate the KEV-listed Cisco ISE exposure using continuous vulnerability management.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is about an actively exploited software flaw requiring timely remediation.
	SI-4 — System Monitoring	Confirming exploitation depends on detecting abnormal API activity and related indicators.
	AC-4 — Information Flow Enforcement	Reducing reachability of the vulnerable API depends on constraining request paths and exposure.
Recommendation — Apply flaw remediation controls to identify, patch, and verify the Cisco ISE vulnerability. Monitor the affected Cisco ISE API for suspicious requests and exploitation indicators. Enforce information flow restrictions so only approved sources can reach the affected API.
NIST CSF 2.0	PR.PS-05 — Identity Management, Authentication, and Access Control	Cisco ISE sits near authentication and access enforcement, so exposure affects control of access paths.
Recommendation — Tighten access controls around the Cisco ISE management and API surface.

Practitioner Guidance

What to verify: Confirm the exact Cisco ISE and ISE-PIC deployment footprint, the exposure of the affected API, and whether any compensating controls actually block untrusted request sources. Do not assume that “internal only” means safe unless you have verified routing, proxying, and network reachability.

Decision rule: If the service is reachable from a network zone you do not fully trust, treat remediation as urgent and prioritise exposure reduction before broader hardening work. If there are indicators of suspicious API activity, move straight to compromise assessment and evidence preservation rather than waiting for a clean patch window.

Practitioner takeaway: With KEV-listed exploitation, the key judgment is not whether the CVE is real, but whether the vulnerable API can still be reached in a way that lets an attacker turn crafted input into meaningful server-side action.

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