CVE-2026-72657

CVE-2026-72657 is an authorization bypass in Fleet Server where an authenticated, enrolled agent could retrieve policies outside its assigned scope by supplying a policy ID directly in the request. The server validated the agent's identity but never checked whether that agent actually had a legitimate relationship to the requested policy — it simply returned the resource if the ID was valid. This is CWE-639 (Authorization Bypass Through User-Controlled Key), and the pattern is structurally predictable, not exceptional. The core failure is conflating authentication with authorization. An enrolled agent proved who it was (authentication), so developers assumed it could be trusted to specify what it wanted (authorization). This is a category error: proving identity establishes identity, not entitlement. The authorization check should have been 'what policies is this agent assigned to?' with server-side membership validation, not 'did the agent provide a well-formed policy ID?' This vulnerability likely emerged from the common pattern where authenticated clients request resources by ID under time pressure. The simpler implementation — validate authentication, accept client-provided identifier, return resource — is measurably cheaper to build, test, and maintain than querying a server-side relationship graph. That's the economic reality that produces this class of flaw repeatedly. More importantly, enrolled-agent credentials have fundamentally different blast radius than user tokens. An agent is infrastructure: it sits inside the trust perimeter, persists across credential rotations, and can probe for lateral relationships. The CVSS 6.5 score misrepresents this risk because it treats an enrolled-agent credential as equivalent to a human user's session token. It isn't. The 'authenticated insider' in this context is a persistent foothold with host-level access, not a privileged employee. The fix requires more than adding a server-side check to the existing API. The design itself must change: agents should request 'give me my policies' (server determines what belongs to this principal) rather than 'give me policy X' (client specifies the target). This eliminates client-supplied identifiers from authorization decisions entirely — a mechanically detectable pattern that tooling can flag at code review time. Architectural patterns worth adopting: treat enrolled-agent authorization as elevated-threat operations requiring additional proof beyond the credential, and treat authorization state as decaying rather than static — policy assignment changes should invalidate cached authorization decisions.

Reviewed through automated stages and approved by a human before publication.