Skip to content

GHSA-ppwx-5jq7-px2w CVE-2026-23999 GO-2026-4564

Fleet: Device lock PIN can be predicted if lock time is known

Medium Go
Severity
0.0 / 10
Medium · CVSS 4.0
Exploit chance (EPSS)
0.14%
Chance of exploitation in the next 30 days. Higher than 3.40% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-330 Use of Insufficiently Random Values
Fix
4.80.1
Upgrade github.com/fleetdm/fleet/v4 to this version or later

Description

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.

Affected versions

Go

PackageVulnerableFixed in
github.com/fleetdm/fleet/v4
< 4.80.1
4.80.1

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/fleetdm/fleet/v4 Go → 4.80.1

go
go get github.com/fleetdm/fleet/v4@v4.80.1 && go mod tidy

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:P/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Attack vector
Physical
Attack complexity
High
Attack requirements
Present
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
None
Integrity (vulnerable system)
High
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

CVSS 3.1 5.5

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Attack vector
Local
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Weakness

CWE-330: Use of Insufficiently Random Values

The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.

How to prevent it
  • Architecture and Design: Use a well-vetted algorithm that is currently considered to be strong by experts in the field, and select well-tested implementations with adequate length seeds. In general, if a pseudo-random number generator is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts. Pseudo-random number generators can produce predictable numbers if the generator is known and the seed can be guessed. A 256-bit seed is a good starting point for producing a "random enough" number.
  • Implementation: Consider a PRNG that re-seeds itself as needed from high quality pseudo-random output sources, such as hardware devices.
  • Architecture and Design, Requirements: Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-rxhg-vcww-2mpw
Fleet: ORDER BY column injection on activity list endpoints
Low Also affects github.com/fleetdm/fleet/v4
GHSA-q9c5-pp7m-fm2g
Fleet: Unauthenticated download of in-house iOS app binaries via predictable URLs
Medium Also affects github.com/fleetdm/fleet/v4
GO-2026-6264
Fleet: SQL injection in Okta conditional access endpoint allows host-controlled compromise of the Fleet database
High Also affects github.com/fleetdm/fleet/v4
GHSA-88p2-jj8w-j8qg
Fleet: Observer-class users can view team enroll secrets and credential-bearing configuration via target search endpoint
Medium Also affects github.com/fleetdm/fleet/v4
GHSA-gm7f-v959-fr2g
Fleet DM Vulnerable to Cross-Team Policy Data Exposure via Global Policy Read Endpoint
Medium Also affects github.com/fleetdm/fleet/v4
GHSA-x4qr-qw6h-wvxq
Fleet: Observer-level enrollment secret extraction via ORDER BY oracle on Apple MDM commands endpoint
Medium Also affects github.com/fleetdm/fleet/v4
GHSA-vxm7-9x8v-8gm4
Fleet has observer-level enrollment secret extraction via ORDER BY oracle on labels host-listing endpoint
Medium Also affects github.com/fleetdm/fleet/v4
GHSA-mxmp-wr3w-rvqx
Fleet: IP spoofing allows bypassing API rate limiting
High Also affects github.com/fleetdm/fleet/v4
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor