CVE-2026-26061
Received Received - Intake
Unauthenticated HTTP Payload DoS in Fleet Device Management

Publication date: 2026-03-27

Last updated on: 2026-03-31

Assigner: GitHub, Inc.

Description
Fleet is open source device management software. Prior to 4.81.0, 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. Version 4.81.0 patches the issue.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-27
Last Modified
2026-03-31
Generated
2026-05-07
AI Q&A
2026-03-27
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
fleetdm fleet to 4.81.0 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-770 The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-26061 is a high-severity vulnerability in the Fleet open source device management software affecting versions prior to 4.81.0.

The issue arises because multiple unauthenticated HTTP endpoints in Fleet read request bodies without enforcing any size limits.

An attacker can exploit this by sending large or repeated HTTP payloads, which causes excessive memory allocation on the Fleet server.

This excessive memory usage can lead to a denial-of-service (DoS) condition where the server process exhausts available memory and may restart, disrupting service availability.


How can this vulnerability impact me? :

This vulnerability can impact you by causing a denial-of-service (DoS) condition on the Fleet server.

An attacker can send large or repeated HTTP requests to exhaust the server's memory, potentially causing the server process to restart and making the service unavailable.

This disruption affects service availability but does not expose sensitive data, nor does it allow authentication bypass, privilege escalation, or data integrity compromise.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring memory usage and server restart patterns for anomalies on the Fleet server.

Since the issue involves unauthenticated HTTP endpoints receiving large or repeated HTTP payloads, you can look for unusual HTTP request patterns or excessive request body sizes targeting the Fleet server.

Specific commands are not provided in the resources, but general approaches include:

  • Using system monitoring tools like 'top', 'htop', or 'free -m' to observe memory usage spikes.
  • Checking server logs for frequent restarts or crashes.
  • Using network monitoring tools like 'tcpdump' or 'wireshark' to capture and analyze HTTP traffic for large or repeated payloads.

What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps before upgrading to Fleet version 4.81.0 or later include:

  • Apply request body size limits at reverse proxies or load balancers such as NGINX or Envoy to prevent excessively large HTTP payloads.
  • Restrict network access to the Fleet server to trusted IP ranges to reduce exposure to unauthenticated attackers.
  • Monitor memory usage and server restart patterns to detect potential exploitation attempts.

How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability causes a denial-of-service (DoS) condition by allowing unauthenticated attackers to send large or repeated HTTP payloads, leading to excessive memory allocation and potential server restarts. However, it does not expose sensitive data, nor does it allow authentication bypass, privilege escalation, or affect data integrity.

Since the vulnerability does not result in data breaches or unauthorized access to personal or protected health information, it is unlikely to directly impact compliance with standards such as GDPR or HIPAA that focus on data confidentiality and integrity.

Nevertheless, the denial-of-service condition could affect service availability, which may be a consideration under certain regulatory requirements that mandate system availability and reliability.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart