Two high-severity denial-of-service vulnerabilities in Fleet, the open-source device management platform used to administer laptops, servers and mobile devices, were published on October 17, and both can be triggered by an attacker with no credentials at all. The flaws, tracked as CVE-2026-111923 and CVE-2026-111924, each carry a CVSS score of 7.5 and can crash a Fleet server outright, taking an organization's device management plane offline with it.
The first flaw affects Fleet versions before 4.89.0. According to the CVE record, Fleet contains an unbounded recursion vulnerability, classed as CWE-674, in the handling of binary property list files at its Apple MDM enrollment endpoints. A remote attacker can send a crafted binary plist payload to those endpoints, and the server's parser recurses without limit as it processes the file, exhausting resources and crashing the service. Because the vulnerable code sits on an enrollment path, it is reachable before a device, or an attacker, has authenticated.
The second flaw, CVE-2026-111924, affects Fleet versions before 4.83.0 and is a more classic decompression problem, classed as CWE-409. Fleet decodes gzip-compressed request bodies sent to unauthenticated endpoints without adequately limiting how much data those bodies can expand into. A small, highly compressed request can therefore balloon during decoding and exhaust server memory, crashing the entire Fleet instance. The record, sourced from the assigning CNA, notes that NVD analysis of the flaw is still pending.
Neither bug requires a foothold, a stolen password or any user interaction, and that is what makes them operationally serious despite denial of service being their only direct impact. Fleet is not a peripheral tool: it is the system administrators use to enroll devices, push configuration and security policies, query endpoints and manage Apple MDM workflows. A crashed Fleet server cannot enroll new machines, and while it is down, IT teams lose the very console they would normally use to see and manage their fleet. An attacker who can repeatedly crash the management server can also blind defenders during a wider incident, or simply impose repeated outages at almost no cost.
The age of the affected ranges underlines the upgrade message. One flaw survived in every release before 4.83.0 and the other in every release before 4.89.0, so any long-running, self-hosted Fleet deployment that has drifted behind on updates is exposed on internet-facing enrollment and API endpoints. There is no indication in the records that either flaw allows data theft or code execution, and administrators should not overstate them, but availability of a management platform is a security property in its own right.
The fix is straightforward: upgrade. Moving to Fleet 4.89.0 or later closes both vulnerabilities, since it sits past the fixed boundary for each. Until the upgrade is done, administrators should restrict network reachability of the Fleet server where their enrollment workflows allow it, confirm which version they are actually running rather than assuming automatic updates applied, and watch server logs for repeated crashes or malformed requests hitting MDM enrollment endpoints. For a platform whose entire job is keeping endpoints visible and manageable, patching the server itself is the first device to manage.