CVE-2023-35078

What it actually does

CVE-2023-35078 is a critical network-exploitable authentication bypass in Ivanti Endpoint Manager Mobile, formerly MobileIron Core. An unauthenticated attacker can reach API functionality that should require administrative authentication. Successful exploitation can expose sensitive EPMM data, including users, devices, LDAP-derived information, and mobile device management metadata, and may allow unauthorized administrative actions depending on exposed configuration and version. Because EPMM commonly integrates with directory services, certificate infrastructure, email, VPN, and mobile device provisioning workflows, compromise can provide high-value information for follow-on intrusion.

Why it matters to the business

Compromise of an internet-facing EPMM server can expose enterprise user and device inventories, enable unauthorized management changes, and create a foothold into broader identity, mobile, and remote-access infrastructure. This vulnerability is in CISA KEV, has extremely high EPSS, is actively exploited in the wild, and has been associated with ransomware activity, so unpatched systems should be treated as urgent incident-response priorities rather than routine patching tasks. The CISA remediation due date was 2023-08-15, indicating long-standing government-recognized exploitation risk.

How an attack unfolds

An attacker scans for exposed Ivanti EPMM or MobileIron Core portals and probes API paths under the EPMM AAD/MIFS interface. The flaw allows requests to restricted API endpoints without completing the normal authentication process. If vulnerable, the server returns data or permits actions that should only be available to authenticated administrators. The attacker can enumerate users and managed devices, collect operational and identity data, and use the information to support credential attacks, social engineering, lateral movement, or chaining with additional Ivanti EPMM vulnerabilities. In observed real-world activity, attackers have targeted internet-facing appliances, often using the bypass as an initial access or reconnaissance mechanism before deeper compromise.

How to fix it

Upgrade Ivanti EPMM/MobileIron Core to a vendor-fixed release or later according to Ivanti guidance for the deployed branch. If the product is end-of-life or cannot be patched immediately, remove internet exposure, restrict access to trusted administrative networks or VPNs, and apply compensating controls such as WAF rules blocking unauthenticated access to /mifs/aad/api/v2/authorized/ paths. Rotate credentials, API tokens, certificates, and integration secrets that may have been exposed through the appliance. Review administrative users and device-management policies for unauthorized changes. Because this vulnerability is actively exploited and listed in KEV with ransomware association, treat any vulnerable externally reachable instance as potentially compromised until investigated.

How to confirm the fix worked

Confirm the appliance reports a fixed Ivanti EPMM version per the vendor advisory and that no unsupported vulnerable versions remain in service. Validate externally that unauthenticated requests to restricted API endpoints, especially /mifs/aad/api/v2/authorized/ paths, return authentication failures such as 401 or 403 rather than 200-series responses or data. Review firewall, reverse proxy, and WAF policy to ensure EPMM administrative and API surfaces are not broadly exposed to the internet. Run authenticated configuration checks where possible and compare appliance build numbers against Ivanti’s fixed release guidance. After remediation, re-run external attack-surface discovery to ensure no duplicate, standby, test, or disaster-recovery EPMM instances remain vulnerable.

Typical attack path

1. Identify internet-exposed Ivanti EPMM or MobileIron Core services through scanning, search engines, or known asset inventories.
2. Send unauthenticated HTTP requests to restricted EPMM API endpoints, especially under /mifs/aad/api/v2/authorized/.
3. Confirm vulnerability when the server returns successful responses or sensitive data without a valid authenticated session.
4. Enumerate users, devices, device ownership, administrative metadata, and mobile-management configuration exposed through the API.
5. Use the collected data for follow-on actions such as privilege escalation, credential targeting, phishing, persistence planning, or chaining with other appliance vulnerabilities.
6. Cover tracks by blending requests with normal HTTPS traffic or rotating source infrastructure.

How to detect it

Investigate EPMM web access logs, reverse proxy logs, WAF logs, load balancer logs, appliance application logs, administrative audit logs, and identity-provider logs. Focus on requests to /mifs/aad/api/v2/authorized/ endpoints that returned HTTP 200, 201, 204, or other successful responses without an authenticated session cookie or from unfamiliar internet addresses. Look for high-volume enumeration of users or devices, repeated requests with adminDeviceSpaceId parameters, unusual HTTP clients such as curl, python-requests, Go clients, scanners, or missing user agents, and access outside normal administrative patterns. Correlate suspicious API access with subsequent creation or modification of administrative users, device-management policies, compliance actions, enrollment settings, certificates, LDAP settings, SCEP/PKI configuration, email/VPN profiles, or service integrations. Preserve full request logs, appliance audit logs, and network metadata before rebooting or rebuilding. If exploitation is suspected, also look for evidence of chained exploitation of other Ivanti EPMM vulnerabilities and downstream activity against accounts, devices, VPN, email, and identity services exposed by EPMM data.

• /mifs/aad/api/v2/authorized/
• /mifs/aad/api/v2/authorized/users
• /mifs/aad/api/v2/authorized/devices
• /mifs/aad/api/v2/authorized/users?adminDeviceSpaceId=
• /mifs/aad/api/v2/authorized/devices?adminDeviceSpaceId=
• GET /mifs/aad/api/v2/authorized/
• POST /mifs/aad/api/v2/authorized/
• GET /mifs/aad/api/v2/authorized/users
• GET /mifs/aad/api/v2/authorized/devices
• adminDeviceSpaceId=
• python-requests
• curl/
• Go-http-client
• 200 "-" "python-requests
• 200 "-" "curl/
• 200 "-" "Go-http-client

What your security team should do

• Immediately inventory all Ivanti EPMM/MobileIron Core instances, including internet-facing, internal, standby, lab, and disaster-recovery systems.
• Patch or upgrade affected appliances as the highest priority; if patching is delayed, isolate the service from the internet and restrict access to trusted networks only.
• Assume exposure may have occurred for any vulnerable externally reachable appliance and initiate incident response, including log preservation and forensic review.
• Search historical access logs for unauthenticated successful requests to /mifs/aad/api/v2/authorized/ endpoints and unusual API enumeration patterns.
• Review EPMM administrative accounts, role assignments, device-management policies, enrollment settings, compliance actions, certificates, and integrations for unauthorized changes.
• Rotate credentials, tokens, certificates, and directory or service-account secrets that could be exposed through EPMM data or integrations.
• Deploy WAF or reverse-proxy detections for suspicious MIFS/AAD API access, while treating these as temporary mitigations rather than a substitute for patching.
• Increase monitoring for follow-on activity against identity systems, VPN, email, mobile device enrollment workflows, and privileged accounts identified in EPMM data.
• Report and handle confirmed exploitation according to incident-response, legal, regulatory, and cyber-insurance obligations, especially where user or device data may have been exposed.