CVE-2026-34385: Second-Order SQL Injection in Fleet Apple MDM Profile Delivery

CVE-2026-34385 identifies a second-order SQL injection (CWE-89) within the Apple Mobile Device Management (MDM) profile delivery subsystem of Fleet. The vulnerability manifests when the platform processes specifically crafted device identifiers during asynchronous job execution. Fleet versions prior to 4.81.0 are vulnerable to this attack vector, provided the Apple MDM functionality is enabled on the target instance.

The attack surface is exposed to any client possessing a valid SCEP-issued MDM enrollment certificate. This requirement enforces a Low Privilege (PR:L) prerequisite, as the attacker must successfully authenticate via mutual TLS (mTLS) during the initial check-in sequence. Unauthenticated, anonymous network requests cannot reach the vulnerable code path.

Exploitation results in severe confidentiality and integrity impacts. The architecture of the Fleet database connection string explicitly enables multi-statement execution. This configuration transforms a standard SQL injection into a vector for stacked queries, allowing an attacker to execute arbitrary INSERT, UPDATE, and DELETE commands against the database backend.

The vulnerability is classified as a second-order SQL injection, characterized by a temporal disconnect between the ingestion of the malicious payload and its execution. During the initial Apple MDM Authenticate check-in, Fleet receives the Unique Device Identifier (UDID) from the client. At this ingestion stage, the application safely stores the provided UDID string in the database utilizing strictly parameterized queries.

The flaw exists in the subsequent processing phase handled by Fleet's asynchronous worker. This worker is responsible for managing MDM profile delivery jobs. When the worker retrieves the previously stored, attacker-controlled UDID from the database, it fails to maintain parameterization. Instead, the application directly interpolates the retrieved UDID string into dynamically constructed SQL statements.

The severity of this unsafe interpolation is compounded by the application's database driver configuration. Fleet initializes the database connection pool with the multiStatements=true parameter. This setting instructs the database driver to accept and execute multiple semicolon-separated SQL commands within a single query payload.

Consequently, an attacker who structures their UDID to terminate the intended query and initiate subsequent commands can bypass standard input validation. The asynchronous worker executes the entire stacked payload with the permissions of the Fleet database user, bypassing the application's intended data access controls.

Exploitation requires the attacker to first provision a device and enroll it with the target Fleet instance. This step is mandatory to obtain the necessary SCEP-issued certificate for mTLS authentication. Once enrolled, the attacker intercepts or customizes the device's communication to manipulate the Apple MDM Authenticate check-in message.

The attacker crafts a specialized SQL injection payload and inserts it into the UDID field of the check-in request. This payload typically begins with syntax designed to cleanly close the expected SQL statement within the asynchronous worker's query template. It is followed by a semicolon and the primary malicious SQL commands, culminating in comment syntax to neutralize any trailing application code.

After the API accepts the check-in and stores the malicious UDID, the attacker must wait for the asynchronous worker to trigger the profile delivery job. This delay represents the second-order nature of the attack. No further user interaction is required; the execution phase relies entirely on the internal scheduling mechanisms of the Fleet application.

Upon execution, the worker interpolates the payload and transmits the stacked queries to the database. Due to the multi-statement configuration, the database sequentially executes all provided commands. The attacker receives no direct synchronous output from the execution, requiring out-of-band exfiltration techniques or reliance on the side effects of database modifications (such as persistent administrative access).

Successful exploitation yields comprehensive control over the Fleet database schema and its records. The ability to execute stacked queries facilitates the extraction of sensitive material stored within the database. Attackers can exfiltrate hashed user credentials, plain-text API tokens, and critical device enrollment secrets utilized by the MDM infrastructure.

The integrity impact is equally critical. Attackers can execute INSERT statements to provision rogue administrative accounts within the users table. This action grants the attacker persistent, high-privileged access to the Fleet web interface and API, entirely bypassing the underlying SQL injection vector for future access.

Furthermore, the attacker can execute UPDATE statements to manipulate global configuration parameters or deploy malicious MDM profiles. By altering profile definitions within the database, the attacker can force the Fleet server to distribute malicious scripts or configuration changes to all other legitimately managed devices across the fleet.

The CVSS v4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:U) accurately reflects this scope. It highlights the network-based attack vector, the requirement for low-level authentication (the mTLS certificate), and the high confidentiality and integrity impacts on the vulnerable system.

The definitive remediation for CVE-2026-34385 is to upgrade the Fleet application to version 4.81.0 or later. The patch addresses the root cause by refactoring the asynchronous worker's database interaction logic. The updated code enforces parameterized queries for all operations involving the UDID, effectively neutralizing the injection vector regardless of the string's content.

Administrators operating environments where immediate patching is strictly prohibited must implement temporary defensive measures. The primary workaround is to disable the Apple MDM functionality within the Fleet configuration. Disabling this feature entirely removes the vulnerable attack surface, as the affected check-in endpoints and associated asynchronous jobs will cease to process incoming requests.

Organizations should also conduct a thorough review of their database logs and user accounts. Incident response teams must search for anomalous SQL queries containing unexpected semicolons or INSERT statements targeting the users table. Identifying newly created administrative accounts or unauthorized modifications to MDM profiles is critical for detecting historical exploitation attempts.