GHSA-Q9C5-PP7M-FM2G: Missing Authorization in Fleet Enterprise iOS Application Distribution Endpoints

Fleet is an open-source device management platform that allows administrators to manage and track operating system hosts, including macOS, Windows, Linux, and iOS devices. In enterprise deployments, organizations often distribute proprietary, in-house iOS applications (represented as .ipa files) to managed devices. This capability relies on specific server-side endpoints to deliver the binary packages and their corresponding XML property list manifest configurations. These manifests contain crucial metadata and direct links to the installation binaries.

The vulnerability, designated as GHSA-Q9C5-PP7M-FM2G, stems from a complete lack of authorization checks on the endpoints serving these custom iOS applications and manifest files in the Enterprise tier of Fleet. Because the Apple Mobile Device Management (MDM) framework expects client devices to fetch certain manifests anonymously during the deployment sequence, the platform skipped standard authorization routines for these routes. This architectural concession exposed sensitive files to the public internet without validating the requester's identity.

This vulnerability corresponds to CWE-862 (Missing Authorization) and specifically affects Fleet versions prior to 4.87.0. The attack surface is exposed directly on the primary HTTP interface of the Fleet server. Since the server relied on sequential, easily guessable database identifiers to locate and serve the assets, any unauthenticated network actor could systematically harvest corporate intellectual property and proprietary binary code.

To understand the root cause, it is necessary to examine how the Apple iOS MDM subsystem initiates the installation of enterprise applications. When a server issues an InstallEnterpriseApplication command, the target iOS device must retrieve an XML manifest plist that points to the actual .ipa binary. Apple's native MDM agent processes these manifest requests in an unauthenticated network context, meaning the client does not present the typical session cookies or bearer tokens associated with a registered user or administrator session.

To accommodate this unauthenticated request flow, Fleet's developers configured the backend router to bypass access control routines specifically for the manifest and package download endpoints. Within the routing controller, developers invoked the svc.authz.SkipAuthorization(ctx) method, effectively disabling all token-based or cookie-based access validation. While this allowed managed iOS devices to download the necessary installation resources, it also permitted any arbitrary HTTP client to access the same routes.

The underlying security flaw was exacerbated by the use of direct, predictable database identifiers in the API request paths. The endpoints mapped directly to the database key fields: /api/latest/fleet/software/titles/:title_id/in_house_app/manifest?fleet_id=:fleet_id. Because the title_id and fleet_id parameters are simple auto-incrementing integers, an attacker did not need to guess complex hashes or UUIDs. Simply iterating from 1 upward allowed immediate resolution of valid database records, illustrating an Insecure Direct Object Reference (IDOR) scenario layered on top of missing authorization logic.

The vulnerable code path resided within the Enterprise-specific service layers. In the legacy implementation of GetInHouseAppManifest, the function bypassed auth and retrieved metadata directly from the datastore using the insecure parameters:

// Vulnerable Implementation
func (svc *Service) GetInHouseAppManifest(ctx context.Context, titleID uint, teamID *uint) ([]byte, error) {
	// Skip authorization to allow MDM clients to fetch the manifest
	svc.authz.SkipAuthorization(ctx)
 
	// Retrieve metadata using sequential IDs
	meta, err := svc.ds.GetInHouseAppMetadataByTeamAndTitleID(ctx, teamID, titleID)
	if err != nil {
		return nil, ctxerr.Wrap(ctx, err, "get in house app manifest: get metadata failed")
	}
 
	// Construct predictable download URL
	downloadURL := fmt.Sprintf("%s/api/latest/fleet/software/titles/%d/in_house_app?fleet_id=%d", 
		appConfig.ServerSettings.ServerURL, titleID, ptr.ValOrZero(teamID))
	...
}

The patch introduced in Pull Request #46819 resolves this by substituting the sequential database query with a random, single-use, time-limited token. The token-based validation pattern replaces the unprotected teamID with a dynamically generated string token:

// Patched Implementation
func (svc *Service) GetInHouseAppManifest(ctx context.Context, titleID uint, token string) ([]byte, error) {
	svc.authz.SkipAuthorization(ctx) // Kept for MDM compatibility
 
	// Explicit token validation check before processing
	tokenMeta, err := svc.validateInHouseAppInstallToken(ctx, titleID, token)
	if err != nil {
		return nil, err // Returns uniform generic error
	}
 
	teamIDPtr := inHouseTeamIDPtr(tokenMeta.TeamID)
	meta, err := svc.ds.GetInHouseAppMetadataByTeamAndTitleID(ctx, teamIDPtr, titleID)
	...
	// Token is appended to the binary download URL to protect the package endpoint
	downloadURL := fmt.Sprintf("%s/api/latest/fleet/software/titles/%d/in_house_app/%s",
		appConfig.ServerSettings.ServerURL, titleID, token)
	...
}

Additionally, the database schema was modified to support the in_house_app_install_tokens table, mapping a 36-character UUID string token to the corresponding host ID, software title ID, and team ID, along with an explicit expires_at timestamp. This architectural change ensures that only devices actively commanded to install an application can access the manifest and binary, and only within a narrow six-hour execution window.

Exploitation of GHSA-Q9C5-PP7M-FM2G is straightforward and requires no advanced tooling. An attacker with basic network access to the Fleet server's API can execute sequential HTTP GET requests targeting the vulnerable URI patterns. Since no authentication cookies or headers are inspected by the server, these requests return valid HTTP 200 responses containing XML manifest files whenever a matching database record is queried.

Once an attacker retrieves a manifest file, they can extract the bundle identifier, the application version, and the exact download link for the primary binary payload. The binary download endpoint (/api/latest/fleet/software/titles/:title_id/in_house_app) similarly lacks any authorization validation, meaning the attacker can directly fetch the compiled iOS package (.ipa file) using the URL found within the manifest.

With the compiled .ipa binary in hand, the attacker can extract the payload and disassemble the application. This allows them to perform static code analysis, extract embedded API keys, identify hardcoded backend services, reverse-engineer proprietary business logic, or discover secondary vulnerabilities within the organization's internal ecosystem.

The security impact of this vulnerability is classified as Medium with a CVSS 3.1 base score of 5.3. Although it does not directly lead to remote code execution on the Fleet server itself or compromise the server's database integrity, it presents a significant risk to organizational confidentiality. Proprietary applications developed for internal enterprise use often contain sensitive business logic, security configurations, and API endpoints that are not intended for public exposure.

By exposing these binaries to unauthenticated parties, the vulnerability significantly lowers the barrier for attackers wishing to perform targeted reverse engineering. Enterprise applications frequently bypass public App Store security reviews and may incorporate weaker input validation, hardcoded credentials, or insecure communication channels under the assumption that they will only run on trusted, managed devices. Exfiltrating these files exposes those weaknesses directly to adversaries.

Furthermore, the metadata leaked within the XML manifests provides valuable reconnaissance data. An attacker can determine what specific security agents, internal portals, or custom tools are deployed across the fleet, allowing them to map out the organization's defensive architecture. This facilitates highly targeted social engineering campaigns or secondary exploitation vectors against the managed iOS client devices themselves.

The definitive resolution for this security flaw is to upgrade the Fleet instance to version 4.87.0 or higher. This upgrade implements the single-use token mechanism and database migrations necessary to restrict access to these endpoints. No manual database reconfiguration is required, as the migration scripts run automatically during the container startup or binary initialization phase of the upgrade sequence.

In environments where upgrading cannot be performed immediately, several temporary workarounds should be applied to limit exposure. Administrators should restrict network-level access to the Fleet server API. Placing the instance behind a virtual private network (VPN) or incorporating Zero-Trust Network Access (ZTNA) ensures that only authenticated corporate users can reach the network routing layer of the Fleet daemon.

Additionally, organizations should audit active in-house software listings. Any legacy or unused custom applications should be removed from the Fleet catalog to minimize the potential attack surface. If possible, avoid embedding high-value secrets or sensitive API configurations in client-side binary builds, relying instead on dynamic, authenticated runtime configuration mechanisms that validate the device's identity prior to provisioning secrets.