CVE-2026-34387 is a critical (CVSS 9.8) command injection in Fleet, the open source device management software. Package metadata is placed into uninstall scripts without sanitizing, which can run code as root or SYSTEM on managed hosts. Upgrade to Fleet 4.81.1 or later.
What's affected
The project's advisory (GHSA-7rhw-5mpv-gp4h) lists the Go module github.com/fleetdm/fleet below 4.81.1 as affected, with 4.81.1 as the patched release.
The advisory explains the path. When an administrator uploads a software package, Fleet extracts metadata such as package identifiers and product names and places them in auto-generated uninstall shell scripts. A crafted package can carry a payload in that metadata. The code runs when an uninstall is triggered for the package, as root on macOS and Linux or SYSTEM on Windows.
The advisory says an attacker would need to get an administrator to upload the crafted package, for example through a supply chain attack, a typosquatted download or a compromised mirror.
How to check if you're exposed
Check your Fleet server version against 4.81.1. Then look at the software library in Fleet: which packages were uploaded, by whom and from where. Packages from unverified downloads deserve a second look.
If you cannot upgrade at once, the advisory suggests inspecting the auto-generated uninstall scripts before deployment.
Pull a list of uploaded packages from the Fleet UI and note the source of each. For any you cannot trace to a vendor download, compare the file's checksum with the one the vendor publishes.
What to do now
- Upgrade the Fleet server to 4.81.1 or later.
- Upload only packages from trusted, verified sources, and check the checksums.
- Review package metadata, not just the install and uninstall scripts, before upload.
- Audit existing uploaded packages for names or identifiers that contain shell characters.
- Hold off triggering uninstalls for packages you cannot vouch for until the upgrade is done.
Why it matters
The weakness is CWE-78, OS command injection. Text taken from a file the attacker controls was placed into a shell script as if it were trusted. Any shell script built from external strings needs quoting or, better, a design that avoids the shell.
The exposure is amplified by where it runs. Device management agents run with the highest privileges on every enrolled machine, so one injected script can reach the entire fleet. The record does not mark the CVE as exploited, and it is not on the CISA KEV list.
There is a supply chain angle. The attack route depends on an administrator trusting a package, whether it came from a typosquatted site or a compromised mirror. Verify checksums and signatures at the point of download, and keep a short list of approved sources. That habit protects you from this bug and from many that have not been found.
The advisory gives one more workaround worth noting: if you cannot upgrade at once, inspect and edit the auto-generated uninstall scripts before deployment. That is slow and easy to get wrong across many packages, so treat it as a bridge to the upgrade and not a plan. After the upgrade, test an uninstall on a lab machine before you run one across the fleet.
Quick check
Does the attacker need an account on Fleet?
The advisory describes an attacker who persuades an administrator to upload a crafted package, so the route runs through a trusted insider.
Sources
Last reviewed: 19 October 2026.
