Notifications
Clear all
Topic starter
19/08/2026 3:45 pm
TL;DR: Two critical Ivanti Endpoint Manager Mobile flaws allow unauthenticated remote code execution, and the vendor says the temporary RPM mitigation is removed by version upgrades, creating a recurring exposure window, according to Intruder. The issue shows that patching edge systems is not just about speed, but about whether the fix survives routine maintenance.
NHIMG editorial — based on content published by Intruder: Ivanti EPMM vulnerabilities allow unauthenticated remote code execution
Questions worth separating out
Q: What fails when a security fix disappears after a routine upgrade?
A: The control fails at the lifecycle level, not just the technical level.
Q: Why do exposed edge management systems create such high risk?
A: They sit close to the boundary between internet traffic and internal administration, so a flaw can become a direct route into privileged control workflows.
Q: How can security teams tell whether a patch programme is actually working?
A: A patch programme is working when installation success is confirmed across the full estate, exploited vulnerabilities are cleared first, and exceptions are measured rather than hidden.
Practitioner guidance
- Validate mitigation durability after every upgrade Re-run the RPM mitigation immediately after any EPMM version change, rebuild, or maintenance action so the fix does not silently vanish.
- Separate patching from exposure verification Confirm whether the affected management interface is internet-facing, then verify that the vulnerable path is no longer reachable before closing the ticket.
- Run compromise checks in parallel with remediation Use the vendor defenders' guide to look for command execution, abnormal processes, and persistence indicators because these flaws were reportedly exploited before disclosure.
What's in the full analysis
Intruder's full article covers the operational detail this post intentionally leaves for the source:
- The exact RPM mitigation workflow and where to obtain it from Ivanti's portal.
- The technical exploit explanation from WatchTowr, including how the Bash breakout works in practice.
- The defenders' guide steps for checking whether an EPMM instance has already been compromised.
- The upgrade scenario that removes the patch and recreates exposure if administrators do not reapply it.
👉 Read Intruder's analysis of the Ivanti EPMM RCE flaws and mitigation caveats →
Ivanti EPMM RCE flaws: are your upgrade controls keeping up?
Explore further
19/08/2026 4:22 pm
Patch persistence, not patch deployment, is the control gap this article exposes. The problem is not simply whether defenders can apply a mitigation quickly. It is whether the remediation survives the operational realities of upgrades, rebuilds, and maintenance windows. That makes change governance part of the security control itself, not an afterthought.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- Our research also found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% only partial visibility.
A question worth separating out:
Q: Who is accountable when an edge platform is patched and then reopened by an upgrade?
A: Accountability should sit with the owners of the system change process, not only the security team. If an upgrade removes a mitigation, that indicates a control design failure across operations, security, and release management. Frameworks such as NIST CSF and NIST 800-53 expect security controls to be governed consistently across the lifecycle.
👉 Read our full editorial: Ivanti EPMM RCE flaws expose patch persistence gaps
