CVE-2026-26061: Unauthenticated Denial of Service via Unbounded Memory Allocation in Fleet

Fleet is an open-source device management platform that interfaces with osquery agents deployed across endpoints. The server exposes several API endpoints to receive telemetry, logs, and distributed query results. These endpoints are typically exposed to the internet to facilitate communication with off-network enrolled devices.

CVE-2026-26061 identifies a resource management flaw in how these internet-facing endpoints process incoming HTTP POST requests. Specifically, the software fails to throttle or limit the size of incoming request bodies. This flaw is classified under CWE-770 (Allocation of Resources Without Limits or Throttling).

Because the vulnerability exists in the HTTP handler layer prior to authentication payload parsing, any external entity can reach the vulnerable code path. The lack of size enforcement allows a remote attacker to force the server to allocate unbounded amounts of memory, ultimately degrading service availability.

The vulnerability originates in the Go HTTP handlers responsible for processing telemetry from osquery agents. When an agent sends data to endpoints such as /api/osquery/log or /api/osquery/distributed/write, the server must parse the JSON payload to extract status logs and query results.

In the vulnerable implementation, the application reads the incoming http.Request.Body directly into a memory buffer without establishing an upper boundary. Go's standard library provides mechanisms like http.MaxBytesReader or io.LimitReader specifically designed to prevent clients from sending exceptionally large payloads that consume excessive server resources.

By omitting these safety constraints, the server relies entirely on the underlying system's available RAM. An attacker transmitting a multi-gigabyte POST request causes the Go runtime to continuously allocate memory slices to buffer the incoming data. This allocation occurs before the application logic validates the enrollment node keys or authenticates the request, making the attack surface universally accessible.

In vulnerable versions of Fleet, the HTTP handlers extract the request body using unbounded reader functions. The implementation typically mirrors the following pattern, where the entire body is read into memory before unmarshaling the JSON content.

// Vulnerable Implementation Pattern
func (h *Handler) ProcessLogs(w http.ResponseWriter, r *http.Request) {
    // Reads the entire request body into memory without constraints
    bodyBytes, err := io.ReadAll(r.Body)
    if err != nil {
        http.Error(w, "Bad Request", http.StatusBadRequest)
        return
    }
    // Processing continues...
}

The remediation introduced in Fleet 4.81.0 implements a strict body size limit using Go's built-in http.MaxBytesReader. This wrapper intercepts the underlying io.ReadCloser. If the read operation exceeds the defined threshold, the reader returns an error, and the connection is closed. This prevents the Go runtime from allocating memory beyond the configured limit.

// Patched Implementation Pattern
func (h *Handler) ProcessLogs(w http.ResponseWriter, r *http.Request) {
    // Limits the request body to a configurable maximum size
    r.Body = http.MaxBytesReader(w, r.Body, h.maxLogBodySizeBytes)
    
    bodyBytes, err := io.ReadAll(r.Body)
    if err != nil {
        // Error is triggered if payload exceeds maxLogBodySizeBytes
        http.Error(w, "Payload Too Large", http.StatusRequestEntityTooLarge)
        return
    }
    // Processing continues safely...
}

An attacker requires only network level access to the Fleet server's exposed API ports to execute this denial-of-service attack. No prior authentication, valid osquery node key, or specialized system configuration is necessary.

The attack begins with the adversary initiating an HTTP POST request to a vulnerable endpoint, such as /api/osquery/log. The attacker utilizes tools like curl, Python, or custom scripts to stream an exceptionally large payload. By setting a massive Content-Length header or utilizing chunked transfer encoding, the attacker streams gigabytes of arbitrary data to the target.

As the Fleet server processes the stream, the Go runtime allocates memory to buffer the incoming request. The server's memory consumption rapidly scales linearly with the size of the payload. Once the host operating system's memory capacity is breached, the Linux Out-Of-Memory (OOM) killer terminates the Fleet process to protect kernel stability.

The primary impact of CVE-2026-26061 is a complete loss of availability for the Fleet service. When the OOM killer terminates the Fleet process, all connected osquery agents lose their management channel. The system can no longer dispatch distributed queries, rotate credentials, or collect security telemetry.

In environments where Fleet serves as a critical component of the security monitoring and incident response infrastructure, this denial-of-service creates a significant visibility gap. Threat actors often execute DoS attacks against monitoring tooling as a precursor to lateral movement or data exfiltration, ensuring their actions are not logged or alerted upon.

The vulnerability carries a CVSS v4.0 score of 8.7. The high severity reflects the ease of exploitation, the lack of authentication requirements, and the complete degradation of service availability. Confidentiality and integrity are not directly impacted by this memory exhaustion vector.

The vendor provides an official patch for CVE-2026-26061 in Fleet version 4.81.0. System administrators must upgrade their Fleet deployments to this version or newer to permanently resolve the vulnerability. The update introduces configurable parameters that limit the maximum acceptable size for incoming osquery HTTP payloads.

Following the upgrade, administrators should evaluate the new body size limit configuration. The limits must be tuned to accommodate the largest legitimate log bundles generated by the environment's osquery agents while remaining small enough to prevent memory exhaustion during an attack.

If immediate patching is not technically feasible, administrators can implement mitigating controls at the reverse proxy or Web Application Firewall (WAF) layer. Configuring size limits on the proxy (for example, utilizing the client_max_body_size directive in Nginx or the SecRequestBodyLimit directive in ModSecurity) will reject oversized payloads before they reach the vulnerable Fleet backend application.