Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Is CVE-2023-35082 (Ivanti Endpoint Manager Mobile (EPMM) and…
Threats, Abuse & Incident Response

Is CVE-2023-35082 (Ivanti Endpoint Manager Mobile (EPMM) and MobileIron Core Authentication Bypass) being exploited in the wild?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 17, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2023-35082 to its Known Exploited Vulnerabilities catalogue on 18 January 2024, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Ivanti Endpoint Manager Mobile (EPMM) and MobileIron Core contain an authentication bypass vulnerability that allows unauthorized users to access restricted functionality or resources of the application.

How the exploitation signal should shape your response

The practical meaning of “being exploited in the wild” is that this is no longer just a theoretical weakness or a future patch item. For CVE-2023-35082, the response should start from the assumption that exposure may already have been attempted or achieved, so the first job is to confirm whether any Ivanti EPMM or MobileIron Core instance is in scope and whether it has been reachable from untrusted networks.

Because CISA has placed the issue in the CISA Known Exploited Vulnerabilities Catalog, you should treat it as an active risk condition, not as a routine hygiene item. The right response is to follow the vendor advisory for fixed versions and mitigation details, then validate which systems were internet-facing, which users or integrations depended on them, and whether administrative access paths were exposed.

What authentication bypass changes in practice

An authentication bypass in a mobile device management or endpoint management product matters because the affected system often sits close to enrollment, device administration, policy enforcement, and sensitive configuration data. If an attacker can reach restricted functionality without proving identity, the issue is not just unauthorized viewing, it can become a control-plane problem with broad downstream impact.

In this kind of product, the most important question is not only whether the bug exists, but what the product could control on behalf of users and administrators if it were accessed improperly. That is why teams should think in terms of management plane exposure, trust boundary failure, and the possibility that an attacker could use the product as a stepping stone into enrolled devices, stored secrets, or administrative workflows.

How to verify exposure, containment, and compromise

Start with a simple exposure check: identify every Ivanti EPMM and MobileIron Core deployment, its network reachability, and whether it was patched or mitigated at the time CISA added the CVE to KEV. Then review authentication, admin, and API logs for unusual access patterns, new accounts, suspicious configuration changes, and requests that do not match normal administrative behavior.

For this class of issue, compromise assessment is as important as remediation. If the instance was reachable before mitigation, examine whether device enrollment records, admin sessions, integration tokens, API usage, or configuration exports show signs of misuse. If the product handled privileged workflows, assume the blast radius may include more than the appliance itself and widen the review to connected management systems and downstream devices.

Risk and Threat Considerations

This vulnerability is attractive to attackers because authentication bypasses on management systems can turn one exposed service into broad administrative reach. In a product that brokers device control and policy enforcement, the attacker may not need to steal a password if the trust decision itself can be bypassed.

Failure mechanism: If the application accepts restricted requests without valid authentication, an attacker can reach privileged functionality, enumerate sensitive data, or alter management settings without a legitimate session.

Impact: The result can include unauthorized administrative access, policy tampering, device or user exposure, and a larger incident if the appliance is used to pivot into connected environments.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0ID.RA-01 — Asset Vulnerability IdentificationActively exploited CVEs require identifying exposed assets and vulnerable services.
PR.AA-05 — Identity Management, Authentication and Access ControlAuthentication bypass directly concerns access control on the management plane.
RS.MA-01 — Incident Management Plan ExecutionKnown exploitation calls for rapid containment and coordinated response actions.
Recommendation — Inventory exposed Ivanti deployments and confirm whether CVE-2023-35082 affected them. Enforce strong authentication and restrict management access paths on EPMM and MobileIron Core. Treat confirmed exposure as an incident and execute containment, forensics, and remediation workflows.
NIST SP 800-53 Rev 5RA-5 — Vulnerability Monitoring and ScanningKEV-listed CVEs require continuous tracking and validation of remediation status.
AC-2 — Account ManagementAuthentication bypass can expose account and administrative access controls.
Recommendation — Track the vulnerability, verify remediation, and rescan affected Ivanti systems. Review privileged accounts and remove any access that the bypass could have exposed.
OWASP ASVSV6 — AuthenticationThe issue is an authentication bypass in an application security context.
V8 — AuthorizationUnauthorized access to restricted functionality is an authorization failure.
V16 — Security Logging and Error HandlingCompromise detection depends on trustworthy logs and error handling.
Recommendation — Validate authentication controls and reject requests that bypass identity verification. Verify that privileged functions remain inaccessible without a valid authenticated role. Ensure access and admin actions are logged well enough to investigate abuse.
OWASP API Security Top 10API2 — Broken AuthenticationThe CVE is an authentication bypass affecting an API-capable management surface.
API5 — Broken Function Level AuthorizationRestricted functionality becomes reachable if function-level checks fail.
Recommendation — Recheck API authentication paths and block unauthenticated management requests. Enforce function-level authorization on all administrative endpoints.

Practitioner Guidance

What to prioritise: Prioritise internet exposure, mitigation status, and compromise assessment before routine patch scheduling. A KEV-listed authentication bypass on a management platform should be treated as a probable incident path until the environment proves otherwise.

What to verify: Verify whether the vulnerable instance was externally reachable, whether the vendor fix or mitigation was applied, and whether logs show admin-like activity that cannot be explained by normal operations. If the logs are incomplete, treat that gap as part of the risk, not as reassurance.

Practitioner takeaway: For actively exploited management-plane flaws, the question is not only “did we patch it?” but “what privileged reach did this system already expose, and what evidence proves it was not abused?”

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 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org