See how fleetdm compares to other vendors in security performance
Summary 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 properly configured proxy or WAF are less affected.
Workarounds If an immediate upgrade is not possible, administrators should ensure Fleet is deployed behind a reverse proxy (e.g., nginx, Cloudflare, AWS ALB) that overwrites X-Forwarded-For with the true client IP, and apply rate limiting at the proxy or WAF layer.
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 @fuzzztf for responsibly reporting this issue.
Summary
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 questions or comments about this advisory:
Email us at [security@fleetdm.com](mailto:security@fleetdm.com)
Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/sharedinvite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)
Credits
We thank @secfox-ai for responsibly reporting this issue.
Summary
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 ingestion is not required. - Monitor for repeated Fleet process crashes or unexpected restarts indicating potential exploitation.
For More Information
If you have any questions or concerns about this advisory, please contact us at:
Email us at security@fleetdm.com
Credits
We thank @fuzzztf for responsibly reporting this issue.
Summary
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 #fleet in osquery Slack
Credits
We thank @zaddy6 for responsibly reporting this issue.
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 comments about this advisory:
Email us at security@fleetdm.com Join #fleet in osquery Slack
Credits
We thank @fuzzztf for responsibly reporting this issue.
Summary
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 is limited to the targeted Windows device.
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 #fleet in osquery Slack
Credits
We thank @secfox-ai for responsibly reporting this issue.
Summary
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.
Fleet is open source device management software. Prior to 4.81.1, a vulnerability in Fleet's Windows MDM command processing allows a malicious enrolled device to access MDM commands intended for other devices, potentially exposing sensitive configuration data such as WiFi credentials, VPN secrets, and certificate payloads across the entire Windows fleet. Version 4.81.1 patches the issue.
Summary
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 that an invite link may have been exposed. - Prefer issuing invites with the minimum required privileges and elevating roles after account creation when appropriate.
For more information
If there are any questions or comments about this advisory:
Send an email to security@fleetdm.com
Credits
Fleet thanks @fuzzztf for responsibly reporting this issue.
Summary
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:
Send an email to security@fleetdm.com
Join #fleet in osquery Slack
Credits
Fleet thanks @fuzzztf for responsibly reporting this issue.
Fleet is open source device management software. Prior to 4.81.1, a command injection vulnerability in Fleet's software installer pipeline allows an attacker to achieve arbitrary code execution as root (macOS/Linux) or SYSTEM (Windows) on managed hosts when an uninstall is triggered for a crafted software package. Version 4.81.1 patches the issue.
Summary
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, affected Fleet users should temporarily disable Apple MDM or limit admin roles.
For more information
If there are any questions or comments about this advisory:
Send an email to security@fleetdm.com
Join #fleet in osquery Slack
Credits
Fleet thanks the Secfox Research Team (@secfox-ai) for responsibly reporting this issue.
Summary
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.
Exploitation requires a valid SCEP-issued enrollment certificate (mTLS), but any enrolled device, including attacker-controlled devices, can exploit this vulnerability.
This issue does not affect instances where Apple MDM is disabled.
Workarounds
If an immediate upgrade is not possible, affected Fleet users should temporarily disable Apple MDM.
For more information
If there are any questions or comments about this advisory:
Send an email to security@fleetdm.com
Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/sharedinvite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)
Credits
Fleet thanks@secfox-ai for responsibly reporting this issue.
Summary
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 maintainer or team admin.
Workarounds
There is no workaround for this issue short of upgrading to a patched version. Organizations concerned about exploitation should audit host transfer activity in their Fleet logs for any unexpected team reassignments.
For more information
If there are 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.
Summary
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 Information
If there are any questions or concerns about this advisory, please contact us at:
Email Fleet at security@fleetdm.com
Credits
Fleet thanks @fuzzztf for responsibly reporting this issue.
Summary
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 contact a Fleet administrator to invalidate active sessions.
For more information
If there are any questions or comments about this advisory:
Email Fleet at security@fleetdm.com Join #fleet in osquery Slack
Credits
Fleet thanks @fuzzztf for responsibly reporting this issue.
Summary
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 possible, administrators should remove the Google Calendar integration from Fleet and rotate the affected Google service account credentials.
For more information
If there are 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.
Summary
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
Workarounds
If an immediate upgrade is not possible, administrators should restrict access to certificate template management to trusted users and avoid delegating team administrator permissions where not strictly required.
For more information
If there are 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.
Summary
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 operations would typically complete before sufficient attempts could be made.
As a result, this issue does not allow remote exploitation, fleet-wide compromise, or bypass of Fleet authentication controls.
Workarounds
There are no known workarounds for this issue. Customers should upgrade to a patched version.
For more information
If there are 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.
Summary
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.
Summary
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 the affected endpoint to trusted roles only and ensure that any user-supplied sort or column parameters are strictly allow-listed at the application or proxy layer.
For more information
If there are any questions or comments about this advisory:
Email fleet at security@fleetdm.com Join #fleet in osquery Slack
Credits
We thank @fuzzztf for responsibly reporting this issue.
Summary
A vulnerability in Fleet’s Windows MDM enrollment flow could allow an attacker to submit forged authentication tokens that are not properly validated. Because JWT signatures were not verified, Fleet could accept attacker-controlled identity claims, enabling enrollment of unauthorized devices under arbitrary Azure AD user identities.
Impact
If Windows MDM is enabled, an attacker can enroll rogue devices by submitting a forged JWT containing arbitrary identity claims. Due to missing JWT signature verification, Fleet accepts these claims without validating that the token was issued by Azure AD, allowing enrollment under any Azure AD user identity.
Patches
- 4.78.3 - 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 disable Windows MDM.
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 this issue.
Summary
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 this issue.
Summary
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 disable Windows MDM.
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 this issue.
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 following backport versions also address this issue:
- 4.63.2 - 4.62.4 - 4.58.1 - 4.53.2
Workarounds
If an immediate upgrade is not possible, Fleet users should temporarily disable single-sign-on (SSO) and use password authentication.
Credit
Thank you @hakivvi, as well as Jeffrey Hofmann and Colby Morgan from the Robinhood Red Team for finding and reporting this vulnerability using our responsible disclosure process.
For more information
If you have any questions or comments about this advisory:
- Email us at security@fleetdm.com - Join #fleet in osquery Slack
fleetdm/fleet is an open source device management, built on osquery. All versions of fleet making use of the teams feature are affected by this authorization bypass issue. Fleet instances without teams, or with teams but without restricted team accounts are not affected. In affected versions a team admin can erroneously add themselves as admin, maintainer or observer on other teams. Users are advised to upgrade to version 4.13. There are no known workarounds for this issue.
fleet is an open source device management, built on osquery. Versions prior to 4.9.1 expose a limited ability to spoof SAML authentication with missing audience verification. 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. Fleet 4.9.1 resolves this issue. Users unable to upgrade should: 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, and When removing access to Fleet in the IdP, delete the Fleet user from Fleet as well.
Fleet is an open source osquery manager. In Fleet before version 3.7.0 a malicious actor with a valid node key can send a badly formatted request that causes the Fleet server to exit, resulting in denial of service. This is possible only while a live query is currently ongoing. We believe the impact of this vulnerability to be low given the requirement that the actor has a valid node key. There is no information disclosure, privilege escalation, or code execution. The issue is fixed in Fleet 3.7.0.
Fleet is an open source osquery manager. In Fleet before version 3.5.1, 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. This issue is patched in 3.5.1. The fix was made using https://github.com/mattermost/xml-roundtrip-validator If upgrade to 3.5.1 is not possible, users should disable SSO authentication in Fleet.