CVE-2026-23517 in fleet
Summary
by MITRE • 01/22/2026
Fleet is open source device management software. A broken access control issue in versions prior to 4.78.3, 4.77.1, 4.76.2, 4.75.2, and 4.53.3 allowed authenticated users to access debug and profiling endpoints regardless of role. As a result, low-privilege users could view internal server diagnostics and trigger resource-intensive profiling operations. Fleet’s debug/pprof endpoints are accessible to any authenticated user regardless of role, including the lowest-privilege “Observer” role. This allows low-privilege users to access sensitive server internals, including runtime profiling data and in-memory application state, and to trigger CPU-intensive profiling operations that could lead to denial of service. Versions 4.78.3, 4.77.1, 4.76.2, 4.75.2, and 4.53.3 fix the issue. If an immediate upgrade is not possible, users should put the debug/pprof endpoints behind an IP allowlist as a workaround.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 02/27/2026
The vulnerability identified as CVE-2026-23517 affects Fleet, an open source device management platform that enables organizations to manage and monitor endpoints across their network infrastructure. This issue represents a critical access control flaw that undermines the security posture of the platform by allowing unauthorized privilege escalation through misconfigured endpoint access controls. The vulnerability specifically impacts versions prior to 4.78.3, 4.77.1, 4.76.2, 4.75.2, and 4.53.3, where the application fails to properly enforce role-based access controls on sensitive debugging and profiling interfaces. The flaw stems from inadequate authorization checks that permit any authenticated user to access debug/pprof endpoints regardless of their assigned role within the system, creating a significant security gap that could be exploited by malicious actors.
The technical implementation of this vulnerability manifests through the failure to properly validate user permissions when accessing internal diagnostic endpoints. In normal operation, these debug and profiling endpoints should be restricted to administrators or users with elevated privileges who require access for system maintenance and troubleshooting purposes. However, the broken access control mechanism allows even the most basic user roles, including the "Observer" role which typically has minimal permissions, to access runtime profiling data and trigger resource-intensive operations. This misconfiguration creates a path for low-privilege users to obtain sensitive information about the internal state of the application, including memory dumps, thread information, and performance metrics that could reveal system architecture and potential attack vectors. The vulnerability directly maps to CWE-285, which addresses improper authorization issues in software systems where access controls are not properly enforced.
The operational impact of this vulnerability extends beyond simple information disclosure to encompass potential service disruption and system compromise. Low-privilege users can trigger CPU-intensive profiling operations that consume significant system resources, potentially leading to denial of service conditions that affect legitimate users and system availability. The exposure of internal server diagnostics provides attackers with valuable insights into the application's runtime behavior, memory structures, and system configuration that could be leveraged for more sophisticated attacks. From an attacker's perspective, this vulnerability creates a stealthy entry point for reconnaissance activities, allowing malicious actors to gather intelligence about the system's internal workings without requiring elevated privileges. The vulnerability also aligns with ATT&CK technique T1211, which covers the exploitation of system privileges and access control weaknesses to gain deeper system access.
Organizations using affected versions of Fleet face significant security risks that require immediate attention through either software upgrades or temporary workarounds. The recommended remediation involves upgrading to versions 4.78.3, 4.77.1, 4.76.2, 4.75.2, or 4.53.3, which contain proper access control enforcement for debug and profiling endpoints. For organizations unable to perform immediate upgrades, implementing an IP allowlist for the debug/pprof endpoints serves as an effective temporary mitigation strategy that limits access to known trusted addresses. This workaround essentially creates a network-level access control boundary that prevents unauthorized remote access to sensitive endpoints while maintaining operational functionality. Security teams should also conduct comprehensive audits of their Fleet deployments to identify any additional misconfigurations and ensure that all debugging interfaces are properly secured according to security best practices and principle of least privilege requirements.