Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
31 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
An authenticated user with read access to Activity could influence the ORDER BY clause of the activity list endpoints by supplying an arbitrary sort column: - GET /api/v1/fleet/activities (ListActivities) - GET /api/v1/fleet/hosts/{id}/activities (ListHostPastActivities) This originated from the deprecated cursor-pagination helper (appendListOptionsWithCursorToSQL), which interpolated the caller-supplied order key into SQL without an allowlist. The original report's nodekey extraction scenario (/api/v1/fleet/labels/{id}/hosts) was remediated separately in #44385; these two activity endpoints were the residual call sites, neither of which joins the hosts table, so nodekey was never reachable through them. Impact Read-only. Because the order key was interpolated, an authenticated user with Activity read could sort by columns not otherwise returned in these responses. The exposure was bounded to columns on activitypast (e.g. details on /api/v1/fleet/activities, which is not in…
Recommended action: Upgrade to 4.89.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Two endpoints serving in-house iOS application packages and manifests in Fleet's enterprise tier are reachable without a hard-to-guess token in the URL, allowing an unauthenticated attacker who can reach the Fleet server to download an in-house IPA by guessing sequential title identifiers. Impact By design, Apple's InstallEnterpriseApplication MDM command requires that the manifest URL be reachable by the managed device without a Fleet session, so these endpoints cannot enforce session-based authentication. Fleet's legacy MDM installer path mitigates this by embedding a random, hard-to-guess token in the URL; the in-house iOS app endpoints (added later) were always intended to use the same time-limited-token pattern but the mitigation was not yet in place. The result is read-only disclosure of in-house IPA binaries and their metadata (bundle identifier, version, name) that an operator has deployed through Fleet. This is enterprise-tier only — the free tier returns…
Recommended action: Upgrade to 4.87.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A SQL injection vulnerability in Fleet's Okta conditional access integration could allow an attacker who controls a single enrolled host to read or modify arbitrary data in the Fleet database, including stored session tokens. Disclosed session tokens may be replayed to act as a global administrator, which on a managed fleet leads to remote code execution on enrolled hosts. Impact When Fleet Premium with Okta conditional access is configured, an unauthenticated request path that supports the conditional access integration uses a host-supplied value in a database query without proper parameterization. Because the value is reported by the host's own agent and stored verbatim, any party that controls one enrolled host (the lowest-privilege role in the product) can influence the query. Successful exploitation could allow: - Disclosure of arbitrary database contents, including credentials and session tokens. - Replay of disclosed session tokens to gain global administrator access.…
Recommended action: Upgrade to 4.86.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The target search endpoint (POST /api/latest/fleet/targets) returned team enroll secrets and full team configuration, including credential-bearing agent options, to observer-class users. Other team-facing endpoints mask these fields for observers; the target search endpoint did not apply the same sanitization. Impact An authenticated user with Observer, Observer+, or Technician role (global or team-scoped) could retrieve unmasked team enroll secrets and team agent options by performing a target search against an observer-runnable query. With a leaked team enroll secret, an attacker could enroll unauthorized hosts into the affected team. If the team's agent options contained credentials such as AWS secret access keys or proxy passwords, those values were also exposed. Patches - v4.87.0 Workarounds If an immediate upgrade is not possible, administrators should: - Rotate team enroll secrets for any team that may have been exposed - Rotate any credentials stored in team agent…
Recommended action: Upgrade to 4.87.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The global policy read endpoint (GET /api/latest/fleet/policies/{policyid}) performs authorization against an empty fleet.Policy{} struct with nil TeamID, then fetches any policy by ID from the database without verifying the fetched policy actually belongs to the global scope. This allows a user with observer-level access on any single team to read the full details of policies belonging to any other team, bypassing Fleet's team isolation model. Details The vulnerability is in GetPolicyByIDQueries at server/service/globalpolicies.go:163-180: The authorization passes because the OPA rule at server/authz/policy.rego:724-728 allows reading policies with null teamid for any user who holds a role on any team: Since the auth object has nil TeamID, this rule fires for any team member. After authorization, ds.Policy() calls policyDB() at server/datastore/mysql/policies.go:283-288 with a nil teamID: This returns any policy regardless of team ownership, and the full policy object is…
Recommended action: Upgrade to 4.85.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in Fleet's Apple MDM commands listing endpoint allowed authenticated users with the lowest-privilege Observer role to extract sensitive values from joined database tables — including host enrollment secrets and Apple Push Notification Service (APNS) tokens — through a cursor-based binary search oracle. The endpoint accepted a user-supplied orderkey parameter that was not validated against a column allowlist. Impact The GET /api/v1/fleet/mdm/apple/commands endpoint constructs its query using a deprecated helper that did not restrict which columns could appear in the ORDER BY clause. The underlying query joins the hosts and nanoenrollments tables, so any column on those tables could be supplied as orderkey. An attacker with Observer credentials could then use the cursor-based pagination parameter (after) to binary-search the value of the chosen column one character at a time. The targeted values never appeared in the response body, but the presence or absence of…
Recommended action: Upgrade to 4.84.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in Fleet's labels host-listing endpoint allowed authenticated users with the lowest-privilege Observer role to extract host enrollment secrets (nodekey, orbitnodekey) through a cursor-based binary search oracle. The endpoint accepted a user-supplied orderkey parameter that was not validated against a column allowlist, permitting sort order to be driven by sensitive columns in a joined table. Impact The GET /api/v1/fleet/labels/{id}/hosts endpoint constructs its query using a deprecated helper that did not restrict which columns could appear in the ORDER BY clause. An attacker with Global Observer or Team Observer credentials could supply a sensitive column name (for example, h.nodekey) as orderkey and combine it with the cursor-based after parameter to binary-search the values of those columns one character at a time. The targeted values never appeared in the response body, but the presence or absence of results revealed each character. The nodekey and…
Recommended action: Upgrade to 4.84.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in Fleet's IP extraction logic allows unauthenticated attackers to bypass API rate limiting by spoofing client IP headers. This may allow brute-force login attempts or other abuse against Fleet instances exposed to the public internet. Impact Fleet extracted client IP addresses from request headers (True-Client-IP, X-Real-IP, X-Forwarded-For) without validating that those headers originate from a trusted proxy. The extracted IP is used as the key for rate limiting and IP ban decisions. As a result, an attacker could rotate the value of these headers on each request, causing Fleet to treat each attempt as coming from a different client. This effectively bypasses per-IP rate limits on sensitive endpoints such as the login API, enabling unrestricted brute-force or credential stuffing attacks. This issue primarily affects Fleet instances that are directly exposed to the internet without a reverse proxy that overwrites forwarded-IP headers. Instances behind a…
Recommended action: Upgrade to 4.80.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in Fleet's software installer pipeline could allow a crafted software package to execute arbitrary commands as root (macOS/Linux) or SYSTEM (Windows) on managed endpoints when an uninstall is triggered. Impact When a software package (.pkg, .deb, .rpm, .exe, or .msi) is uploaded to Fleet, metadata is extracted from the package binary and used to generate uninstall scripts. In affected versions, this metadata is not properly sanitized before being included in the generated scripts. A specially crafted package containing malicious values in its metadata fields could result in unintended command execution when the uninstall script runs on managed endpoints. Workarounds If an immediate upgrade is not possible, administrators should avoid uploading software packages obtained from untrusted or unverified sources. Additionally, administrators can manually inspect and edit auto-generated uninstall scripts before deployment. For more information If you have any…
Recommended action: Upgrade to 4.81.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fleet contained a denial-of-service (DoS) issue in the gRPC Launcher PublishLogs endpoint. In affected versions, certain unexpected input values were not handled gracefully, which could cause the Fleet server process to terminate while processing an authenticated request from an enrolled Launcher host. Impact An authenticated attacker with access to any enrolled Launcher node key could cause an immediate and complete denial of service by sending a single gRPC request to the PublishLogs endpoint. This vulnerability impacts availability only. There is: - No exposure of sensitive data - No authentication bypass - No privilege escalation - No integrity impact Workarounds If upgrading immediately is not possible, the following mitigations can reduce exposure: - Restrict network access to the Fleet gRPC endpoint where feasible (for example, limiting inbound access to known host IP ranges). - Deploy Fleet behind infrastructure that terminates or filters gRPC traffic if Launcher log…
Recommended action: Upgrade to 4.81.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in Fleet's Windows MDM enrollment flow allows authentication tokens from any Azure AD tenant to be accepted. Because Fleet validates JWT signatures using Microsoft's multi-tenant JWKS endpoint but does not enforce the aud (audience) or iss (issuer) claims, any Microsoft-signed Azure AD access token containing the expected scopes can be used to authenticate to Fleet's MDM endpoints. Impact If Windows MDM is enabled, an attacker with access to any Azure AD tenant can obtain a valid Microsoft-signed token and use it to enroll unauthorized devices and interact with Fleet's MDM management APIs. During device management, Fleet may expose sensitive enrollment secrets embedded in MDM command payloads, enabling further unauthorized access. Workarounds If an immediate upgrade is not possible, affected Fleet users should temporarily disable Windows MDM. For more information If you have any questions or comments about this advisory: Email us at security@fleetdm.com Join…
Recommended action: Upgrade to 4.82.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Fleet trusted client-supplied IP address headers when determining the source IP for incoming requests. This allowed authenticated and unauthenticated clients to spoof their apparent IP address and bypass per-IP rate limiting controls. Fleet determines a client’s public IP address using HTTP headers such as: - X-Forwarded-For - X-Real-IP - True-Client-IP These headers were trusted without validation. An attacker could supply arbitrary values in these headers, causing Fleet to treat each request as originating from a different IP address. This could allow an attacker to bypass per-IP rate limits and increase the effectiveness of brute-force or password-spraying attempts against authentication endpoints. This issue does not allow authentication bypass, privilege escalation, data exposure, or remote code execution on its own. Workarounds Run Fleet behind a trusted reverse proxy or load balancer that overwrites client IP headers. For more information If you have any questions or…
Recommended action: Upgrade to 4.80.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in Fleet’s Windows MDM management endpoint could allow requests to be processed without proper client certificate validation. In certain circumstances, this could allow an attacker to impersonate an enrolled Windows device and retrieve sensitive configuration data. Impact Fleet’s Windows MDM management endpoint relies on mutual TLS (mTLS) client certificates to authenticate enrolled devices. In affected versions, requests that did not present a client certificate could be incorrectly treated as trusted. As a result, an attacker with prior knowledge of a valid enrolled device identifier could potentially impersonate that device and receive configuration payloads intended for it. These payloads may contain sensitive information such as Wi-Fi or VPN configuration data, certificates, or other secrets delivered through MDM profiles. This issue does not allow enrollment of new devices, administrative access to Fleet, or compromise of the Fleet control plane. Impact…
Recommended action: Upgrade to 4.81.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Orbit agent's FileVault disk encryption key rotation flow on collects a local user's password via a GUI dialog and interpolates it directly into a Tcl/expect script executed via exec.Command("expect", "-c", script). Because the password is inserted into Tcl brace-quoted send {%s}, a password containing } terminates the literal and injects arbitrary Tcl commands. Since Orbit runs as root, this allows a local unprivileged user to escalate to root privileges. CWE - CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - CWE-94: Improper Control of Generation of Code ('Code Injection') Impact - Local privilege escalation to root: Any unprivileged local user on a managed endpoint can execute arbitrary commands as root Credit This vulnerability was discovered and reported by bugbunny.ai.
Recommended action: Upgrade to 4.81.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fleet contained an issue in the user invitation flow where the email address provided during invite acceptance was not validated against the email address associated with the invite. An attacker who obtained a valid invite token could create an account under an arbitrary email address while inheriting the role granted by the invite, including global admin. Impact If an attacker gains access to a valid invite token, they can create a Fleet user account with an email address of their choosing while inheriting the invite’s assigned role and team memberships. This issue: - Requires possession of a valid invite token - Does not bypass authentication controls beyond invite-based account creation - Does not expose data without successful account creation Workarounds If upgrading immediately is not possible: - Treat invite links as sensitive credentials and avoid sharing them in public or semi-public channels (e.g., Slack, Teams). - Revoke and reissue invites if there is any concern…
Recommended action: Upgrade to 4.81.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Denial of Service vulnerability in Fleet's gRPC Launcher endpoint allows an authenticated host to crash the entire Fleet server process by sending an unexpected log type value. The server terminates immediately, disrupting all connected hosts, MDM enrollments, and API consumers. Impact An attacker with access to a valid Launcher node key can send a specially crafted gRPC request to the Fleet server that triggers an unrecoverable server crash. The gRPC server lacks appropriate error recovery handling, meaning the entire Fleet process terminates rather than gracefully rejecting the malformed input. Because the crash is instant and repeatable, an attacker could script repeated requests to prevent the server from recovering, resulting in a persistent denial of service until a patched version is deployed. Workarounds There is no workaround for this issue other than upgrading to a patched version. For more information If there are any questions or comments about this advisory:…
Recommended action: Upgrade to 4.81.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A SQL Injection vulnerability in Fleet's MDM bootstrap package configuration allows an authenticated user with Team Admin or Global Admin privileges to modify arbitrary team configurations, exfiltrate sensitive data from the Fleet database, and inject arbitrary content into team configs via direct API calls. Impact An authenticated user with Team Admin or Global Admin role can exploit a flaw in how user-supplied input is handled during MDM bootstrap package configuration. Insufficient server-side input validation allows crafted input to manipulate database queries in unintended ways. Successful exploitation could enable cross-team data corruption, exfiltration of sensitive information such as password hashes and API tokens, and potential privilege escalation. Exploitation requires authentication with team or global admin privileges and MDM to be enabled. This issue does not affect instances where Apple MDM is disabled. Workarounds If an immediate upgrade is not possible,…
Recommended action: Upgrade to 4.81.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A critical second-order SQL Injection vulnerability in Fleet's Apple MDM profile delivery pipeline could allow an attacker with a valid MDM enrollment certificate to exfiltrate or modify the contents of the Fleet database, including user credentials, API tokens, and device enrollment secrets. Impact If Apple MDM is enabled, an attacker controlling an enrolled device can send a malicious UDID during the MDM Authenticate check-in. The UDID is stored safely via parameterized queries, but is later interpolated directly into SQL when the async worker processes the job. This enables blind, boolean-based, and UNION-based SQL injection across four simultaneous subqueries. Because Fleet's database driver is configured with multiStatements=true, the attacker can also execute stacked queries, enabling arbitrary writes to the database. This includes inserting new admin accounts, modifying configuration, deploying malicious profiles or scripts to managed devices, and deleting data.…
Recommended action: Upgrade to 4.81.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A broken access control vulnerability in Fleet's host transfer API allows a team maintainer to transfer hosts from any team into their own team, bypassing team isolation boundaries. Once transferred, the attacker gains full control over the stolen hosts, including the ability to execute scripts with root privileges. Impact The host transfer endpoints verify that the caller has write permission to the destination team but do not check whether the caller has any permission over the source team of the hosts being transferred. Once hosts are transferred, the attacker's team MDM configuration is automatically applied to the stolen devices, and the attacker can execute scripts on them with root privileges. In multi-tenant Fleet deployments where teams represent business units, departments, or customers, this breaks all team isolation guarantees. A bulk transfer variant allows stealing all matching hosts fleet-wide in a single request. Exploitation requires authentication as a team…
Recommended action: Upgrade to 4.81.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/fleetdm/fleet/v4 < 4.43.5-0.20260113202849-bbc1aef2987d
Fixed in
4.43.5-0.20260113202849-bbc1aef2987d· Vendor fix available
Issue
Fleet contained multiple unauthenticated HTTP endpoints that read request bodies without enforcing a size limit. An unauthenticated attacker could exploit this behavior by sending large or repeated HTTP payloads, causing excessive memory allocation and resulting in a denial-of-service (DoS) condition. Impact An unauthenticated attacker could cause the Fleet server process to exhaust available memory and restart by sending oversized or repeated HTTP requests to affected endpoints. This vulnerability impacts availability only. There is: - No exposure of sensitive data - No authentication bypass - No privilege escalation - No integrity impact Workarounds If upgrading immediately is not possible, the following mitigations can reduce exposure: - Apply request body size limits at a reverse proxy or load balancer (e.g., NGINX, Envoy). - Restrict network access to endpoints to known IP ranges where feasible. - Monitor memory usage and restart frequency for abnormal patterns. For More…
Recommended action: Upgrade to 4.43.5-0.20260113202849-bbc1aef2987d (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/fleetdm/fleet/v4 < 4.43.5-0.20260113202849-bbc1aef2987d
Fixed in
4.43.5-0.20260113202849-bbc1aef2987d· Vendor fix available
Issue
A vulnerability in Fleet’s password management logic could allow previously issued password reset tokens to remain valid after a user changes their password. As a result, a stale password reset token could be reused to reset the account password even after a defensive password change. Impact If an attacker had prior access to a valid password reset token, they could reuse that token within its validity window to reset the user’s password after the user has already changed it. This could result in temporary account takeover. Exploitation requires prior compromise of a password reset token and is further constrained by the token’s 24-hour expiration period. The issue does not allow discovery of reset tokens, does not bypass authentication on its own, and does not affect accounts without an existing valid reset token. Workarounds Until patched, users who believe a password reset token may have been exposed should wait for the token to expire before reusing the account, or…
Recommended action: Upgrade to 4.43.5-0.20260113202849-bbc1aef2987d (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in Fleet’s configuration API could expose Google Calendar service account credentials to authenticated users with low-privilege roles. This may allow unauthorized access to Google Calendar resources associated with the service account. Impact Fleet returns configuration data through an API endpoint that is accessible to authenticated users, including those with the lowest-privilege “Observer” role. In affected versions, Google Calendar service account credentials were not properly obfuscated before being returned. As a result, a low-privilege user could retrieve the service account’s private key material. Depending on how the Google Calendar integration is configured, this could allow unauthorized access to calendar data or other Google Workspace resources associated with the service account. This issue does not allow escalation of privileges within Fleet or access to device management functionality. Patches - v4.80.1 Workarounds If an immediate upgrade is not…
Recommended action: Upgrade to 4.80.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A broken authorization check in Fleet’s certificate template deletion API could allow a team administrator to delete certificate templates belonging to other teams within the same Fleet instance. Impact Fleet supports certificate templates that are scoped to individual teams. In affected versions, the batch deletion endpoint validated authorization using a user-supplied team identifier but did not verify that the certificate template IDs being deleted actually belonged to that team. As a result, a team administrator could delete certificate templates associated with other teams, potentially disrupting certificate-based workflows such as device enrollment, Wi-Fi authentication, VPN access, or other certificate-dependent configurations for the affected teams. This issue does not allow privilege escalation, access to sensitive data, or compromise of Fleet’s control plane. Impact is limited to integrity and availability of certificate templates across teams. Patches - v4.80.1…
Recommended action: Upgrade to 4.80.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in Fleet’s Android MDM Pub/Sub handling could allow unauthenticated requests to trigger device unenrollment events. This may result in unauthorized removal of individual Android devices from Fleet management. Impact If Android MDM is enabled, an attacker could send a crafted request to the Android Pub/Sub endpoint to unenroll a targeted Android device from Fleet without authentication. This issue does not grant access to Fleet, allow execution of commands, or provide visibility into device data. Impact is limited to disruption of Android device management for the affected device. Workarounds If an immediate upgrade is not possible, affected Fleet users should temporarily disable Android MDM. For more information If there any questions or comments about this advisory: Email Fleet at security@fleetdm.com Join #fleet in osquery Slack Credits Fleet thanks @secfox-ai for responsibly reporting this issue.
Recommended action: Upgrade to 4.80.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fleet generated device lock and wipe PINs using a predictable algorithm based solely on the current Unix timestamp. Because no secret key or additional entropy was used, the resulting PIN could potentially be derived if the approximate time the device was locked is known. Impact Fleet’s device lock and wipe commands generate a 6-digit PIN that is displayed to administrators for unlocking a device. In affected versions, this PIN was deterministically derived from the current timestamp. An attacker with physical possession of a locked device and knowledge of the approximate time the lock command was issued could theoretically predict the correct PIN within a limited search window. However, successful exploitation is constrained by multiple factors: - Physical access to the device is required. - The approximate lock time must be known. - The operating system enforces rate limiting on PIN entry attempts. - Attempts would need to be spread over multiple days. - Device wipe…
Recommended action: Upgrade to 4.80.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.