Yes. CISA added CVE-2020-15505 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Ivanti MobileIron's Core & Connector, Sentry, and Monitor and Reporting Database (RDB) products contain an unspecified vulnerability that allows for remote code execution.
What “being exploited in the wild” means for this CVE
For a KEV-listed CVE, the practical question is not whether exploitation is theoretically possible, but whether organisations should treat it as an active attack path. For CVE-2020-15505, that means assuming exposure may already be targeted wherever Ivanti MobileIron Core, Connector, Sentry, or RDB are reachable and still in service.
Because the vulnerable products sit in a trust-bearing management and remote access role, exploitation can have consequences well beyond the initial foothold. A successful attacker may be able to execute code on the appliance, use that access to inspect connected systems, or pivot into adjacent administrative workflows if the environment is poorly segmented.
When a product family is already on CISA’s KEV catalogue, the key operational assumption is that defenders should not wait for proof of compromise before acting. The relevant question becomes whether you have those products deployed, whether they are internet-facing or reachable by attackers, and whether compensating controls limit what a compromised appliance can touch.
How to confirm exposure and prioritise response
The first task is simple inventory confirmation. Identify every instance of the affected Ivanti MobileIron product family, including management nodes, connectors, reporting components, and any dependent services that may share credentials, administrative trust, or network reach with the exposed system.
Then determine whether the asset is directly reachable from untrusted networks, whether remote administration is enabled, and whether it sits on a path to internal authentication systems, secrets stores, or management planes. If the appliance is broadly trusted, the blast radius of exploitation is larger even when the vulnerability itself is confined to one product.
Prioritisation should follow exploited-vulnerability discipline, not generic patch queues. CISA’s KEV listing is the strongest signal that this belongs in emergency response, and the vendor advisory should be used for exact version and remediation details rather than guessed from secondary sources.
For context on response sequencing, teams often pair KEV triage with a vulnerability management workflow that distinguishes exposure, business criticality, compensating controls, and verification after remediation. That avoids treating every CVE as equal while still moving known exploited flaws to the front of the queue.
What to do if patching must wait
If immediate remediation is not possible, reduce attacker reach and reduce the usefulness of any foothold. Restrict management access to tightly controlled admin networks, remove unnecessary internet exposure, and review whether the appliance can still initiate outbound connections that would let an attacker stage tooling or exfiltrate data.
Where the product supports it, tighten authentication paths, minimize standing administrative access, and confirm that adjacent credentials are not reused elsewhere. The more a device can authenticate to other systems, the more important it becomes to treat the appliance as a potential credential and session exposure point.
If compensating controls are the only option for a short period, document the exception, assign an owner, and set a deadline for removal. A temporary exception without a hard expiry becomes a standing exposure, which is exactly how exploited vulnerabilities turn into long-lived footholds.
Risk and Threat Considerations
KEV inclusion means defenders should assume real-world exploitation pressure, not just abstract product risk. For remote code execution flaws in management appliances, attackers often aim for initial execution, then persistence, credential theft, and internal pivoting because those systems sit close to privileged operations.
Failure mechanism: The appliance is trusted to handle administrative or routing functions, so code execution on the device can be converted into broader environment access when segmentation, monitoring, or credential hygiene is weak.
Impact: A compromise can expose administrative data, service credentials, and internal management pathways, and may enable follow-on intrusion into systems that were never intended to be directly reachable from the internet.
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 | KEV-listed RCEs need prioritized scanning and remediation. |
| Recommendation — Prioritise and remediate KEV-listed flaws first, then verify exposure closure. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | Exposed appliances require hardening and controlled configuration changes. |
| DE.CM-01 — Networks and network services are monitored to find events | Active exploitation calls for monitoring likely appliance abuse and pivoting. | |
| Recommendation — Harden exposed appliances and remove unnecessary attack surface. Monitor appliance logs and network paths for signs of exploitation. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Exploit-in-the-wild CVEs require prompt correction and tracking. |
| AC-17 — Remote Access | Management appliances need tightly controlled remote administration paths. | |
| Recommendation — Accelerate remediation for the vulnerable appliance and confirm completion. Restrict remote administration to approved management networks only. | ||
Practitioner Guidance
What to verify: Confirm whether any Ivanti MobileIron deployment is still present, whether it is internet-facing, and whether its trust relationships extend into privileged network or identity systems. If the answer is unclear, assume the exposure is operationally material until proven otherwise.
Decision rule: If the system is exposed and you cannot patch immediately, treat containment as a priority equal to remediation. Reduce access paths first, then verify whether the appliance has already been used as a launch point for lateral movement or credential exposure.
Edge Device Security Guide is useful here because the response pattern is the same for exposed management appliances: inventory, restrict management reach, and assume the trust boundary matters more than the product label.
Zero-Day and Exploited Vulnerabilities Guide fits the response logic for actively exploited flaws, especially the need to combine emergency mitigation with post-remediation hunting.
Vulnerability Management Guide supports the prioritisation decision, especially where teams need a defensible way to move KEV-listed issues ahead of ordinary backlog work.
CISA Known Exploited Vulnerabilities Catalog should be checked directly for current status and required remediation timing.
NIST National Vulnerability Database remains the reference point for the canonical CVE record and product metadata.
Practitioner takeaway: For a KEV-listed appliance flaw, the real decision is not whether exploitation is possible, but whether your current exposure path is already acceptable to an attacker.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2020-15505 (Ivanti MobileIron Multiple Products Remote Code Execution)?
- CVE-2020-15505 (Ivanti MobileIron Multiple Products Remote Code Execution)
- Is CVE-2022-47966 (Zoho ManageEngine Multiple Products Remote Code Execution) being exploited in the wild?
- Is CVE-2022-35405 (Zoho ManageEngine Multiple Products Remote Code Execution) being exploited in the wild?
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