CVE-2026-23518: 
NixOS vulnerability analysis and mitigation

CVE-2026-23518 is a JWT signature bypass vulnerability in Fleet's Windows MDM enrollment flow that allows unauthenticated remote attackers to enroll unauthorized devices under arbitrary Azure AD user identities. Affecting Fleet (open-source device management software) versions prior to 4.53.3, 4.75.2, 4.76.2, 4.77.1, and 4.78.3, the flaw was disclosed on January 20, 2026, via a GitHub Security Advisory (Github Advisory). It carries a CVSS v3.1 base score of 9.8 (Critical) and a CVSS v4.0 base score of 9.3 (Critical) (Github Advisory, Feedly).

The root cause is classified as CWE-347 (Improper Verification of Cryptographic Signature): Fleet's GetAzureAuthTokenClaims function previously used jwt.Parser.ParseUnverified() to process Azure AD JWTs during Windows MDM enrollment, meaning the cryptographic signature was never validated against Azure AD's public keys (Github Advisory). An unauthenticated network attacker can craft a JWT with arbitrary identity claims (e.g., any Azure AD UPN, tenant ID, or scope) and submit it to the MDM enrollment endpoint; Fleet accepts these claims as legitimate without verifying they were signed by Azure AD (Github Advisory). The fix, committed in e225ef5, replaces ParseUnverified with a proper jwt.Parse call that fetches Azure AD's JWKS from https://login.microsoftonline.com/common/discovery/v2.0/keys and validates the token's kid and alg headers against the retrieved public keys (Fleet Commit). Exploitation requires only that Windows MDM be enabled on the Fleet instance; no credentials or user interaction are needed.

Successful exploitation allows an attacker to enroll rogue or attacker-controlled devices into the Fleet MDM system under any Azure AD user identity, effectively bypassing device authentication and authorization controls (Github Advisory). This compromises the integrity of the device management environment, potentially enabling attackers to receive MDM policies, commands, and configuration profiles intended for legitimate managed endpoints. The broader organizational risk includes unauthorized access to managed endpoint data, lateral movement through MDM-distributed configurations, and erosion of trust in the device inventory — all with high confidentiality, integrity, and availability impact ratings (Feedly).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the time of disclosure (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.043–0.059%, placing it in the 19th percentile for exploitation likelihood within 30 days (Github Advisory). The vulnerability was responsibly disclosed by researcher @secfox-ai (GitHub: prateek-0490) (Github Advisory). Despite the low EPSS, the zero-authentication requirement and network accessibility make this a high-priority patching target for organizations with Windows MDM enabled.

1. Reconnaissance: Identify Fleet instances with Windows MDM enabled by probing the MDM discovery endpoint (e.g., POST /api/mdm/microsoft/discovery) or by scanning for Fleet's MDM service URLs exposed on the network.
2. Craft a forged JWT: Construct a JWT with arbitrary Azure AD identity claims — including a target upn (user principal name), tid (tenant ID), unique_name, and scp: mdm_delegation — signed with any key (e.g., a self-generated HMAC or RSA key), since the server does not verify the signature.
3. Base64-encode the token: Encode the crafted JWT using standard Base64 encoding, as Fleet decodes the BinarySecurityToken from Base64 before parsing.
4. Submit enrollment request: Send a crafted SOAP enrollment request to Fleet's Windows MDM enrollment endpoint (e.g., MDE2EnrollPath) with the forged token embedded in the BinarySecurityToken field of the WSTEP message.
5. Achieve unauthorized enrollment: Fleet accepts the forged identity claims without signature validation, enrolling the attacker's device under the impersonated Azure AD user identity, granting it access to MDM policies and commands (Github Advisory, Fleet Commit).

• Network: Unexpected SOAP enrollment requests to Fleet's Windows MDM enrollment endpoint (MDE2EnrollPath) originating from unknown or unmanaged IP addresses; outbound connections from the Fleet server to Azure AD JWKS endpoints may be absent (pre-patch) or newly present (post-patch).
• Logs: Fleet server logs showing successful Windows MDM enrollments for Azure AD identities not associated with known organizational devices; enrollment events lacking corresponding Azure AD sign-in activity for the claimed user.
• Device Inventory: Appearance of unrecognized or unexpected devices in the Fleet host inventory with Windows MDM enrollment status, particularly devices whose hardware IDs do not match known organizational assets.
• MDM Activity: MDM policy or command delivery to devices not provisioned through standard organizational workflows; devices enrolled under high-privilege Azure AD user identities without corresponding IT provisioning records (Github Advisory).

Fleet has released patched versions: 4.78.3, 4.77.1, 4.76.2, 4.75.2, and 4.53.3 — organizations should upgrade to the appropriate patched version for their deployment branch (Github Advisory). If an immediate upgrade is not feasible, the recommended workaround is to temporarily disable Windows MDM in Fleet to prevent unauthorized device enrollment until the patch can be applied (Github Advisory). After patching, administrators should audit the Fleet device inventory for any unauthorized or unrecognized enrolled devices and revoke their enrollment. For questions, Fleet's security team can be reached at security@fleetdm.com.

The vulnerability was responsibly reported by researcher @secfox-ai and credited in the official advisory published by Fleet maintainer lukeheath on January 20, 2026 (Github Advisory). Coverage appeared on security aggregation platforms including Vulners, CVEFeed, and Bluesky CVE tracking accounts shortly after disclosure. Red Hat also tracked the CVE in their security database (Feedly). No significant broader media coverage or notable researcher commentary beyond the official advisory has been identified.