CVE-2026-23518 Overview
CVE Identifier: CVE-2026-23518
Severity: Critical
CVSS v4 Base Score: 9.3 – very high severity
Primary Affected Component: Fleet device management software – Windows MDM enrollment flow
Core Issue: Improper cryptographic validation — JWT signature bypass
Impact: Unauthorized device enrollment under arbitrary user identities
Affected Versions: Fleet versions prior to the patched releases below
Fix Availability: Yes — official patches are released
Official Patch Link: https://github.com/fleetdm/fleet/security/advisories/GHSA-63m5-974w-448v
What This Vulnerability Really Is
Fleet is an open-source platform used to manage fleets of corporate devices — desktops, laptops, servers — often with integration into identity systems like Azure Active Directory (Azure AD). Part of managing Windows devices includes enrolling those devices into Fleet’s Mobile Device Management (MDM) system.
During Windows MDM enrollment, Fleet expects a JSON Web Token (JWT) from the identity provider (e.g., Azure AD) that asserts who the user or device is. That token must be validated cryptographically, meaning the server has to check the signature to ensure it was really issued by the trusted identity provider and not forged.
In affected Fleet versions, the code that accepts these JWTs did not correctly verify the signature on certain Windows MDM enrollment requests. In other words, the server would take the identity claims in the token at face value without confirming that the token was correctly signed by Azure AD or another trusted issuer.
This is a fundamental authentication flaw. Because of it, an attacker who can reach Fleet’s enrollment endpoint can:
- Craft a JWT with identity claims pointing to any Azure AD user you care about
- Submit that forged JWT to the Windows MDM enrollment endpoint
- Have Fleet accept it as legitimate
- Enroll a rogue device under the identity the attacker chose
Once that rogue device is enrolled, it appears to the rest of the system like a legitimate managed device belonging to a real user. That opens the door to unauthorized access, policy changes, data collection, and potentially internal resource access depending on your environment.
How This Could Be Exploited
To exploit this issue, an attacker needs:
- Network access to Fleet’s Windows MDM endpoint — this could be internal or exposed externally depending on your deployment.
- Ability to construct a forged JWT — this doesn’t require any stolen credentials; it simply means the attacker fabricates a token that Fleet will accept because it doesn’t verify the signature.
- Craft an enrollment request using that forged token to enroll an attacker-controlled device.
When Fleet processes the request, it believes the token is valid. It associates the rogue device with the identity in the token — potentially a high-privilege account. The attacker now has a managed device inside your MDM system, effectively bypassing intended enrollment controls.
Why This Matters
This vulnerability allows remote unauthenticated actors to bypass authentication entirely. Because there is no signature verification, tokens can be fully fabricated. That means:
- Confidentiality risk: Unauthorized devices could appear trusted and receive sensitive policies or telemetry.
- Integrity risk: Attackers could impersonate identities and enroll devices with the same privileges as real users.
- Availability risk: Misused devices could be used to push malicious configurations or disrupt legitimate management.
In environments where device identity gates access to services or internal networks, this weakness undermines core security assumptions.
Is There a Known Exploit or PoC?
As of the latest advisories, no public working proof-of-concept exploit has been published by reliable sources. That does not mean the flaw is not exploitable — it’s inherently exploitable by design if an attacker can send HTTP requests to Fleet’s enrollment endpoint. Given the nature of the flaw, it is theoretically possible to craft such a request.
Because the vulnerability involves lack of signature verification — a logic flaw — attackers don’t need complex payloads. The exploit consists of forging a token with arbitrary identity claims. Any elevated access or lateral movement following that initial enrollment depends on your environment.
Mitigation: Update or Temporarily Disable
The only complete fix is to update Fleet to a version where this flaw has been addressed. Official fixes are available in these versions:
- 4.78.3
- 4.77.1
- 4.76.2
- 4.75.2
- 4.53.3
If you cannot update immediately due to operational constraints:
- Disable Windows MDM in Fleet until a patch can be applied.
- Restrict access to the MDM enrollment endpoint via firewall, VPN, or allow-lists.
- Monitor and alert on unexpected enrollment attempts.
Official production releases and updates can be found here:
🔗 Official Patch / Advisory: https://github.com/fleetdm/fleet/security/advisories/GHSA-63m5-974w-448v
How to Detect Attempts to Exploit This Issue
You should assume that if the vulnerability exists in your environment, attackers could attempt to exploit it. Below are ways to find signs of exploitation.
1. Audit Enrollment Logs
Look at Fleet’s logs, focusing on:
- Enrollment attempts that occur outside typical business hours
- Enrollment attempts where the claimed identity doesn’t match corresponding identity provider logs (Azure AD sign-ins)
- Enrollment logs that lack a valid token verification record
If your log structure records whether a token was verified, look for entries where “signature verification skipped” or “no signature present” appears.
2. Correlate with Identity Provider Records
Compare Fleet enrollment attempts with Azure AD logs to confirm:
- The token’s issuer
- The time of token issuance
- Whether the token in the enrollment request matches a real issued token
If there’s an enrollment with no corresponding valid Azure AD token issuance, treat it as suspicious.
3. Web Server / Proxy Logging
If you front Fleet with a web server or load balancer:
- Search for POST requests to the Windows MDM enrollment endpoint
- Look for request bodies or Authorization headers containing JWTs with anomalous structure (e.g., malformed tokens, missing signature section)
Many logging systems can regex match JWT patterns — a JWT normally has three parts separated by two dots (HEADER.PAYLOAD.SIGNATURE). A token missing the third part suggests tampering.
4. Suspicious Device Patterns
After the flaw existed but before patch, monitor for:
- A sudden spike in new device enrollments
- Devices enrolling with unusual hostnames or IP addresses
- Devices that do not show corresponding provisioning activity in identity logs
These are signs something may be off.
Detection Rules You Can Deploy
Here are defender-focused guidance patterns you can implement in your SIEM or EDR systems.
SIEM / Log Monitoring Concepts
Look for:
- HTTP POSTs to Fleet’s MDM enrollment API
- Tokens where the “alg” header indicates no signature or missing signature
- Enrollment requests from IPs not typically seen in your normal environment
Rule Template
Create a rule that triggers on:
- Enrollment attempt logged
AND - A parsed JWT from the request that is malformed or missing a signature
OR - Enrollment request where identity claims (like user ID) are not backed by an actual token issuance in identity provider logs
These rules help defenders reduce false positives by correlating identity systems with MDM activity.
Investigation Checklist
If you suspect exploitation, follow this structured approach:
- Identify affected Fleet instances — find which ones run versions older than the patched releases.
- Gather enrollment logs from Fleet and its reverse proxy/web server for the window of vulnerability.
- Pull identity provider logs (Azure AD) for tokens issued during that same window.
- Correlate token-issued times with Fleet’s enrollment times.
- Flag devices enrolled without corresponding token issuance.
- Quarantine those devices and audit them manually.
- Patch Fleet immediately and revalidate your enrollment workflows.
Final Takeaway
- Update Fleet to a patched version immediately.
- Disable Windows MDM if patching will be delayed.
- Harden access to your Fleet management interface and APIs.
- Monitor and correlate logs between Fleet, identity providers, and network logs for suspicious behavior.
- Investigate and remediate any devices enrolled during the vulnerable period without proper authentication verification.
