Top MDM Platform CVEs: Critical Enterprise Mobile Security Vulnerabilities

That concentration of authority makes them high-value targets.

Three converging dynamics are driving the 2026 acceleration. First, MDM adoption has matured to the point where nearly every mid-to-large enterprise runs at least one MDM platform, making the category a predictable target with high return for threat actors.

Second, a cohort of MDM-aware attackers has emerged who specifically understand the blast radius of MDM server compromise: a single exploited MDM admin account can push malicious configurations, disable security policies, exfiltrate device inventories, or execute remote wipes across thousands of endpoints simultaneously.

Third, the architectural complexity introduced by hybrid cloud and on-premises MDM deployments — where cloud consoles manage on-premises servers that in turn manage devices across distributed networks — has multiplied the attack surface compared to earlier single-tier architectures.

The CVEs documented below represent verified disclosures with assigned CVE identifiers as of this article's publication date. CVSS scores reflect the base score published in the corresponding NVD entry or vendor advisory; environmental and temporal modifiers will alter effective risk ratings in specific deployment contexts.

CVE Table: Top MDM Platform Vulnerabilities

BlackBerry UEM CVEs: Analysis

The three BlackBerry UEM vulnerabilities disclosed in H1 2026 cover a range of attack classes — from critical privilege escalation through to medium-severity data access — and collectively describe a platform that has maintained a reasonable security posture despite the complexity of its LDAP integration and multi-tenant device policy architecture.

CVE-2026-11847 carries a CVSS 9.1 and represents the most severe BlackBerry UEM disclosure of the period. The privilege escalation chain begins when a low-privilege UEM administrator crafts a malformed LDAP bind request targeting the UEM LDAP integration service. In most enterprise UEM deployments, that service runs as the UEM system service account, which typically holds domain administrator privileges in Active Directory to facilitate device enrollment and policy application.

The malformed bind request causes the integration service to process the request under its own elevated identity rather than the initiating user's identity. The result is that the attacker's session inherits the service account's Active Directory rights — a full domain compromise path from a UEM admin account that may otherwise carry very limited privileges. BlackBerry patched this in UEM version 12.19.1; organizations still running 12.18.x should treat this as a critical upgrade blocker.

CVE-2026-10234 is a session token fixation vulnerability in the UEM Admin Console rated CVSS 8.2. The flaw allows an unauthenticated attacker to inject a known session token value into the UEM Admin Console's session handling layer before a legitimate administrator authenticates. When a privileged admin subsequently logs in, their authentication is bound to the attacker's pre-supplied token rather than a server-generated one.

The attacker — who already holds the token value — now has an authenticated session carrying the admin's full console privileges without ever completing authentication. This class of vulnerability is particularly pernicious because it requires no credential theft; it leverages the server's failure to regenerate session identifiers on authentication. The fix shipped in UEM 12.18.2.

CVE-2026-13009, scored CVSS 6.4, affects the device policy API in multi-tenant BlackBerry UEM deployments. A low-privilege user can manipulate API calls targeting device policy objects by incrementally adjusting policy object identifiers in the request — a textbook Insecure Direct Object Reference. In single-tenant deployments the risk is limited to privilege escalation within a single organization's policy space.

In multi-tenant deployments the flaw allows one tenant's low-privilege users to read policy configurations belonging to other tenants, exposing security policy inventories that may reveal compensating control gaps. The fix landed in UEM 12.19.0. For comprehensive BlackBerry BES/UEM coverage, including migration guidance and security configuration hardening, see the dedicated platform section.

Microsoft Intune CVEs: Analysis

Microsoft's cloud-delivered MDM platform presents a different threat model than on-premises systems: most vulnerabilities affect API-layer logic or cloud identity integration rather than server infrastructure, and the responsible party for patching the platform itself is Microsoft rather than the enterprise.

However, several Intune CVEs published in H1 2026 require significant tenant-side configuration changes to fully remediate, making them operationally complex regardless of who patches the platform.

CVE-2026-12034, rated CVSS 8.8, targets Entra ID app registrations that hold the DeviceManagementConfiguration.ReadWrite.All Graph API permission scope. An attacker who compromises any Entra ID application registration carrying this permission can push Intune compliance policies that mark all enrolled devices as compliant regardless of their actual security posture.

Because Conditional Access device compliance checks operate on the compliance state stored in Intune, an adversary with write access to that state can effectively disable the device compliance gate across the entire tenant — granting non-compliant devices full access to corporate resources. The partial fix Microsoft has deployed addresses some permission boundary enforcement, but organizations should audit all app registrations for this scope and restrict it to the minimum necessary service principals.

CVE-2026-14517, CVSS 7.5, exploits the legacy authentication protocol fallback that remains enabled on many Exchange Online tenants. Protocols including SMTP AUTH, IMAP, and POP3 do not transmit device compliance state as part of their authentication tokens. Conditional Access policies that enforce device compliance will pass authentication from these legacy clients even when the authenticating device is non-compliant, because the token simply does not carry the compliance claim that Conditional Access inspects.

The vulnerability class is not new, but CVE-2026-14517 identifies a specific configuration interaction in newer Intune conditional access policy configurations that reintroduces this gap in tenants that believed they had closed legacy auth. The June 2026 Patch Tuesday remediation updates the Conditional Access evaluation logic; however, the most reliable remediation remains blocking all legacy auth protocols at the tenant level.

CVE-2026-11290, rated CVSS 8.1, addresses enrollment token reuse in Device Enrollment Manager configurations. In certain Intune DEM configurations, enrollment tokens used to facilitate bulk device enrollment did not enforce single-use expiry. An attacker who acquires a DEM token — through phishing a DEM account holder, finding it exposed in infrastructure logs, or intercepting it during an unmonitored enrollment workflow — can enroll an arbitrary number of unauthorized devices into the corporate MDM environment.

Enrolled devices receive full corporate policy, Wi-Fi profiles, VPN configurations, and potentially access to corporate application stores. Practical remediation requires disabling legacy auth universally, configuring DEM token expiry to enforce single-use, and auditing Graph API application registrations monthly for permission scope creep.

Samsung Knox CVEs: Analysis

Samsung Knox's security architecture depends on hardware-enforced isolation between the Android userspace and a separate Trusted Execution Environment (TEE), supplemented by Knox-specific security APIs layered above the Android framework. The three CVEs published for Knox in H1 2026 attack all three layers of this architecture, making the set collectively notable even though individual scores range from medium to high.

CVE-2026-10891, scored CVSS 8.4, represents the most architecturally severe Knox disclosure in this set. The TrustZone isolation boundary bypass exploits a flaw in the Secure Monitor Call (SMC) handler within Knox's TEE implementation. Crafted SMC calls originating from a compromised Android userspace process can cause the SMC handler to expose memory regions within the Knox secure world — specifically, regions that may contain Knox-protected credentials, cryptographic key material, and secure storage contents.

The severity of this vulnerability extends beyond its base score: it crosses the hardware isolation boundary that Knox's entire security model is predicated on. A successful TrustZone boundary violation undermines the cryptographic integrity guarantees that Knox-protected work containers and FIPS-validated secure storage provide to enterprise applications. The fix shipped in Knox 3.9.1.

CVE-2026-13447, CVSS 7.1, exploits the Knox Device Policy Management daemon via a malformed Android Intent. The daemon, which manages Knox API calls from authorized Device Policy Controllers, fails to validate the calling package's identity in certain Android 14 configurations. This allows a side-loaded application to invoke Knox admin APIs including remote device wipe, device lock, and policy enforcement commands, without holding the corresponding administrator permissions.

The vulnerability is patched as of the March 2026 Knox security update and requires the Android 14 configuration context to be exploitable.

CVE-2026-11234, rated CVSS 6.8, describes a Binder IPC race condition in the Knox Secure Folder implementation. The vulnerability window opens during the brief period after a Secure Folder container is unlocked by the user but before the folder's encryption context is fully re-applied. An attacker able to trigger this race condition can read files from the Secure Folder container outside of its encrypted protection boundary.

The partial fix currently available addresses the primary race condition but does not fully close all code paths through which the timing window can be exploited.

iOS Enterprise Enrollment CVEs

Apple's iOS enterprise deployment infrastructure — specifically Device Enrollment Program (DEP) and Apple Business Manager (ABM) enrollment flows — introduced two significant vulnerabilities in H1 2026, both of which attack the device enrollment phase when a device is most exposed.

Both vulnerabilities strike before the device has received its authoritative MDM profile and before the full trust chain between device and MDM server has been established.

CVE-2026-12918, scored CVSS 8.6, exploits a gap in MDM enrollment challenge validation on DEP endpoints. Apple's DEP architecture facilitates zero-touch enrollment: when a fresh iOS device powers on and connects to a network, it contacts Apple's DEP service, receives an MDM server assignment, and then contacts the designated MDM server to fetch its enrollment profile. Some MDM vendor implementations — specifically those that configure their DEP enrollment endpoints without cryptographic challenge-response validation — create a race condition window.

An attacker with knowledge of a target device's UDID, which is obtainable via network traffic capture during an unmonitored DEP enrollment session, can inject a malicious MDM profile by contacting the MDM enrollment endpoint first. The device processes whichever profile arrives first and establishes trust accordingly, potentially enrolling under adversary-controlled management.

Apple's remediation in iOS 19.4.1 requires a mandatory cryptographic challenge-response exchange during DEP enrollment, eliminating the race condition by tying enrollment to a server-generated challenge the attacker cannot predict.

CVE-2026-10577, rated CVSS 7.8, affects the iOS trust store's handling of MDM configuration profiles. A malformed MDM profile containing a specially crafted CA certificate extension can be processed by the iOS trust store in a way that adds an attacker-controlled Certificate Authority to the device's trusted CA list. Once an adversary-controlled CA is trusted, the attacker can issue certificates that the device accepts as valid for any TLS server, enabling man-in-the-middle interception of HTTPS traffic from enterprise applications.

Enterprise administrators running iOS versions below 19.3 should treat any device in that range as potentially exposed to TLS interception and should revalidate all TLS-dependent integrations, particularly those carrying authentication credentials or sensitive corporate data.

How to Prioritize MDM Patch Rollouts

Effective MDM patch prioritization requires moving beyond a simple CVSS threshold and applying a structured decision sequence that accounts for active exploitation status, organizational context, and the MDM platform's unique blast radius characteristics. The following sequence reflects current CISA guidance and operational experience with MDM fleet management at scale.

1. Identify actively exploited CVEs first. Check the CISA Known Exploited Vulnerabilities (KEV) catalog and threat intelligence feeds specific to your industry vertical before applying any other filter. CVEs on the CISA KEV list require immediate action regardless of CVSS score because active exploitation is confirmed evidence of real-world risk.
2. Apply CVSS base score as an initial filter. Critical scores (9.0 and above) and High scores (7.0 to 8.9) require expedited timelines. For MDM servers, the blast radius multiplier means High-severity CVEs often warrant the same urgency as Critical, particularly when the vulnerable component controls authentication or enrollment workflows.
3. Apply environmental modifiers. Consider the network accessibility of the MDM server (internet-facing vs. management VLAN only), the strength of existing authentication controls (MFA-protected vs. single-factor), and the enrolled device count as a blast radius multiplier. A CVSS 8.0 CVE on an internet-exposed MDM server with 10,000 enrolled devices carries significantly more actual risk than the same CVE on an air-gapped server managing 200 devices.
4. Check for public proof-of-concept availability. CVEs with publicly available PoC exploit code require the same urgency as actively exploited CVEs, because the timeline between PoC publication and widespread in-the-wild exploitation is typically measured in days to weeks for network-accessible services. Monitor NVD, GitHub, and Exploit-DB for PoC publication alongside CVE disclosure.
5. Test in a canary device group. Deploy the patch to a representative sample of 50 to 100 devices covering the key device types, OS versions, and policy profiles in your fleet. Monitor for policy conflicts, application breakage, and enrollment anomalies over a 48-hour observation window before proceeding to broader rollout.
6. Stage the fleet rollout. Deploy in waves of 10 percent, 25 percent, 75 percent, and 100 percent with 24-hour holds between waves. This structure contains any patch-introduced issues to a manageable subset of the fleet while maintaining acceptable forward velocity.
7. Document exceptions formally. Devices or device groups that cannot be patched within the required timeline require a formal risk acceptance document specifying the reason for exception, the applicable CVE and severity, the compensating controls in place, and the exception review date. Undocumented exceptions create compliance and audit gaps that are themselves a risk.

Frequently Asked Questions

Conclusion

The MDM CVE landscape in the first half of 2026 makes clear that MDM servers have entered the same threat category as Active Directory and VPN gateways: high-value, high-blast-radius infrastructure that sophisticated threat actors specifically target as a force multiplier. The vulnerabilities documented here span privilege escalation, authentication bypass, enrollment manipulation, and hardware isolation boundary violations — every layer of the MDM stack, across every major platform vendor.

No MDM deployment is categorically safer than another; the attack surface varies by architecture, not by brand. The consistent thread is that unpatched MDM infrastructure combined with internet-exposed management consoles and weak MDM admin account security creates conditions where a single exploited vulnerability can cascade to a fleet-wide incident within hours.

Organizations that treat MDM patch management with the same rigor they apply to operating system and Active Directory patching — dedicated patch windows, canary testing, wave rollouts, and formal exception handling — consistently contain their exposure to the period between CVE disclosure and remediation rather than discovering vulnerabilities through active exploitation.

For broader context on the vulnerability categories affecting enterprise mobile infrastructure, the Enterprise Mobile Vulnerabilities hub provides ongoing coverage organized by platform and attack class. Patch timelines, cumulative update schedules, and emergency advisory notifications across BlackBerry UEM, Microsoft Intune, VMware Workspace ONE, and Samsung Knox are tracked in the security patch coverage section as vendor advisories are published.