# Ivanti EPMM addUser validation bypass and impersonation

Source: https://startwithidentity.com/cves/cve-2025-55129/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

## What broke

Ivanti EPMM did not validate the `addUser` path the way the rest of the admin API did. An attacker could create a user or impersonate one. Ivanti patched. Ivanti MDM products have a long KEV history even when a specific ID is not yet listed.

## Why it matters

EPMM decides which devices are trusted for [Conditional Access](https://startwithidentity.com/glossary/conditional-access/) and which users get email. Impersonation there bypasses the device-trust story your IdP thinks it is enforcing.

## What to do

- Patch EPMM. Confirm every appliance, including DR.
- Review users created through the API around the disclosure window.
- Do not expose EPMM admin to the internet. Pair device compliance with [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), not instead of it.

## After you patch

Patching closes the entry point. It does not remove access an attacker established through it.

- **Revoke sessions and API tokens** on the affected system rather than only resetting passwords.
- **Audit accounts, tokens, and administrative changes** made during the exposure window.
- **Rotate credentials the system stored or could reach**, including directory service accounts and integration keys. See [secrets rotation](https://startwithidentity.com/glossary/secrets-rotation/).
- **Treat the system as a pivot**: whatever it could authenticate to is in scope until you have checked it.

## Sources

- [NVD: CVE-2025-55129](https://nvd.nist.gov/vuln/detail/CVE-2025-55129)
- Ivanti security advisory