CVE-2026-26061: 
NixOS vulnerability analysis and mitigation

CVE-2026-26061 is a denial-of-service vulnerability in FleetDM Fleet caused by unbounded HTTP request body reads on multiple unauthenticated endpoints. An unauthenticated remote attacker can send oversized or repeated HTTP payloads to trigger excessive memory allocation, causing the Fleet server process to exhaust available memory and restart. All Fleet versions prior to 4.81.0 are affected. The vulnerability was disclosed on March 27, 2026, with a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 8.7 (High) (GitHub Advisory, Github Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): Fleet's HTTP server reads request bodies from multiple unauthenticated endpoints without enforcing any size limit, allowing an attacker to force unbounded memory allocation. Because no authentication is required and no size cap is enforced, an attacker can send arbitrarily large or repeated HTTP POST/PUT requests to these endpoints over the network with low complexity and no user interaction. The vulnerability was responsibly disclosed by researcher @fuzzztf (GitHub Advisory). No public proof-of-concept exploit code has been observed as of the time of this report (Feedly).

Successful exploitation results in a denial-of-service condition: the Fleet server process exhausts available memory and restarts, disrupting availability for all users and managed endpoints relying on the Fleet server. The impact is strictly limited to availability — there is no exposure of sensitive data, no authentication bypass, no privilege escalation, and no integrity impact (GitHub Advisory). In environments where Fleet is used for device management and security monitoring, repeated exploitation could cause sustained operational disruption and gaps in endpoint visibility.

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation as of the time of this report (Feedly). The EPSS score is approximately 0.051% (0.023% per GitHub Advisory), placing it in a low percentile for near-term exploitation likelihood. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the attack requires no authentication, no special privileges, and no user interaction, making it trivially automatable if targeted (Github Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible Fleet server instances (default port 8080/443) using tools like Shodan, Censys, or internal network scanning. Confirm the version is below 4.81.0.
2. Identify unauthenticated endpoints: Review Fleet's API documentation or probe the server for HTTP endpoints that accept request bodies without requiring authentication tokens or session cookies.
3. Craft oversized payloads: Prepare large HTTP request bodies (e.g., multi-megabyte or gigabyte-sized POST bodies) targeting the identified unauthenticated endpoints.
4. Send repeated or oversized requests: Use tools such as curl, wrk, or custom scripts to send a high volume of large HTTP requests to the vulnerable endpoints, forcing the server to allocate memory for each request body without releasing it promptly.
5. Trigger memory exhaustion: The Fleet server process accumulates excessive memory allocations, eventually exhausting available system memory and causing the process to crash and restart, resulting in a DoS condition (GitHub Advisory).

• Network: Unusually large or high-frequency HTTP POST/PUT requests to Fleet server unauthenticated endpoints from unexpected source IPs; sustained high inbound traffic volume to Fleet's HTTP port.
• Logs: Fleet access logs showing repeated requests with abnormally large Content-Length headers or chunked transfer encoding from a single or small set of source IPs; error log entries indicating out-of-memory conditions or process restarts.
• Process/System: Sudden spikes in Fleet server process memory consumption visible in system monitoring tools (e.g., top, htop, Prometheus metrics); unexpected Fleet server process restarts or crash dumps.
• Application: Fleet server becoming unresponsive or returning 5xx errors during or after a burst of large requests; monitoring alerts for Fleet service availability failures (GitHub Advisory).

Upgrade Fleet to version 4.81.0 or later, which enforces request body size limits on affected endpoints (GitHub Advisory). If immediate upgrading is not possible, apply the following mitigations: configure request body size limits at a reverse proxy or load balancer (e.g., client_max_body_size in NGINX or equivalent in Envoy); restrict network access to Fleet endpoints to known, trusted IP ranges; and monitor Fleet server memory usage and restart frequency for anomalous patterns. Contacting Fleet's security team at security@fleetdm.com is recommended for additional guidance (Github Advisory).

The vulnerability was responsibly disclosed by researcher @fuzzztf and remediated by MagnusHJensen as the remediation developer, with the advisory published by lukeheath on behalf of FleetDM (GitHub Advisory). The CVE was picked up by standard vulnerability aggregators including VulnDB, CIRCL, and ENISA's EUVD shortly after disclosure, with no notable broader media coverage or significant social media discussion identified beyond automated CVE notification channels.