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.
A SQL Injection vulnerability in Fleet’s software versions API allowed authenticated users to inject arbitrary SQL expressions via the orderkey query parameter. Due to unsafe use of goqu.I() when constructing the ORDER BY clause, specially crafted input could escape identifier quoting and be interpreted as executable SQL. Impact An authenticated attacker with access to the affected endpoint could inject SQL expressions into the underlying MySQL query. Although the injection occurs in an ORDER BY context, it is sufficient to enable blind SQL injection techniques that can disclose database information through conditional expressions that affect result ordering. Crafted expressions may also cause excessive computation or query failures, potentially leading to degraded performance or denial of service. No direct evidence of reliable data modification or stacked query execution was demonstrated. Workarounds If an immediate upgrade is not possible, users should restrict access to…
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.
Go github.com/fleetdm/fleet/v4 < 4.78.3-0.20260112221730-5c030e32a3a9
Fixed in
4.78.3-0.20260112221730-5c030e32a3a9· Vendor fix available
Issue
A broken access control issue in Fleet allowed authenticated users to access debug and profiling endpoints regardless of role. As a result, low-privilege users could view internal server diagnostics and trigger resource-intensive profiling operations. Impact Fleet’s debug/pprof endpoints are accessible to any authenticated user regardless of role, including the lowest-privilege “Observer” role. This allows low-privilege users to access sensitive server internals, including runtime profiling data and in-memory application state, and to trigger CPU-intensive profiling operations that could lead to denial of service. Patches - 4.78.3 - 4.77.1 - 4.76.2 - 4.75.2 - 4.53.3 Workarounds If an immediate upgrade is not possible, users should put the debug/pprof endpoints behind an IP allowlist. For more information If you have any questions or comments about this advisory: Email us at security@fleetdm.com Join #fleet in osquery Slack Credits We thank @secfox-ai for responsibly reporting…
Recommended action: Upgrade to 4.78.3-0.20260112221730-5c030e32a3a9 (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.20260111020427-0e6c790803d1
Fixed in
4.43.5-0.20260111020427-0e6c790803d1· Vendor fix available
Issue
A cross-site scripting (XSS) vulnerability in Fleet’s Windows MDM authentication flow could allow an attacker to compromise a Fleet user account. In certain cases, this could lead to administrative access and the ability to perform privileged actions on managed devices. Impact If Windows MDM is enabled, an attacker could exploit a cross-site scripting (XSS) vulnerability by convincing an authenticated Fleet user to visit a malicious link. Successful exploitation could allow retrieval of the user’s Fleet authentication token from their browser. A compromised authentication token may grant administrative access to the Fleet API, allowing an attacker to perform privileged actions such as deploying scripts to managed hosts. This issue does not allow unauthenticated access and does not affect instances where Windows MDM is disabled. Patches - 4.78.2 - 4.77.1 - 4.76.2 - 4.75.2 - 4.53.3 Workarounds If an immediate upgrade is not possible, affected Fleet users should temporarily…
Recommended action: Upgrade to 4.43.5-0.20260111020427-0e6c790803d1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
4.58.14.63.24.62.44.53.24.64.2· Vendor fix available
Issue
A vulnerability in Fleet’s SAML authentication handling could allow an attacker to forge authentication assertions and gain unauthorized access to Fleet. In certain configurations, this could result in the creation of new user accounts, including administrative accounts. This issue affects Fleet deployments using single sign-on (SSO). Impact In vulnerable versions of Fleet, an attacker could craft a specially-formed SAML response to: - Forge authentication assertions, potentially impersonating legitimate users. - If Just-In-Time (JIT) provisioning is enabled, the attacker could provision a new administrative user account. - If MDM enrollment is enabled, certain endpoints could be used to create new accounts tied to forged assertions. This could allow unauthorized access to Fleet, including administrative access, visibility into device data, and modification of configuration. Patches This issue is addressed in commit fc96cc4 and is available in Fleet version 4.64.2. The…
Recommended action: Upgrade to 4.64.2, 4.63.2, 4.62.4 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Due to issues in Go's standard library XML parsing, a valid SAML response may be mutated by an attacker to modify the trusted document. This can result in allowing unverified logins from a SAML IdP. Users that configure Fleet with SSO login may be vulnerable to this issue. Patches This issue is patched in 3.5.1 using https://github.com/mattermost/xml-roundtrip-validator. Workarounds If upgrade to 3.5.1 is not possible, users should disable SSO authentication in Fleet. References See https://mattermost.com/blog/coordinated-disclosure-go-xml-vulnerabilities/ for more information about the underlying vulnerabilities. For more information If you have any questions or comments about this advisory: Email us at security@fleetdm.com Join #fleet in osquery Slack
Recommended action: Upgrade to 3.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This impacts deployments using SAML SSO in two specific cases: 1. A malicious or compromised Service Provider (SP) could reuse the SAML response to log into Fleet as a user -- only if the user has an account with the same email in Fleet, and the user signs into the malicious SP via SAML SSO from the same Identity Provider (IdP) configured with Fleet. 2. A user with an account in Fleet could reuse a SAML response intended for another SP to log into Fleet. This is only a concern if the user is blocked from Fleet in the IdP, but continues to have an account in Fleet. If the user is blocked from the IdP entirely, this cannot be exploited. Patches Fleet 4.9.1 resolves this issue. Workarounds and good practices Reduce the length of sessions on your IdP to reduce the window for malicious re-use. Limit the amount of SAML Service Providers/Applications used by user accounts with access to Fleet. When removing access to Fleet in the IdP, delete the Fleet user from Fleet as well. For…
Recommended action: Upgrade to 4.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.