CVE-2026-72630

This CVE exposes a temporal authorization gap in Elastic Defend policy management within the Fleet API. The vulnerability is not a missing authorization check — it's that the check evaluates against the current state of a policy rather than its requested post-change state. When a user with Elastic Defend privileges updates a policy to change its integration type (e.g., reassigning an endpoint policy to a different integration), the system validates the user's Elastic Defend privilege against the stored policy — which is still an endpoint policy — and grants access. The authorization then permits a state change it should have denied, because it never evaluated whether the user holds privileges over what the policy will become. The root cause traces to when the capability to reassign policies between integration types was added. The original privilege model implicitly assumed integration type was immutable post-creation — a structural constraint the authorization model relied on without explicit boundary definition. When reassignment was introduced as a convenience feature, it was treated as a pure functionality addition and not audited against existing privilege scopes. That's the actual vulnerability: a correctly-scoped privilege that became over-permissive because a new feature changed what the object could become. For defenders: First, audit your Fleet API endpoints for policy update paths that accept integration type parameters. Determine whether any authenticated users hold Elastic Defend privileges and also have access to policy modification — that population is your exploit surface. Second, review whether policy reassignment between integration types is an intentional feature in your deployment; if not, disabling it restores the original security model. Third, the correct fix evaluates authorization against the requested integration type, not the stored one — but verify the patch covers all code paths that can trigger type conversion, including indirect paths through policy templates or bulk operations. Finally, check audit logs for policy updates where integration_type changed between the pre-update and post-update metadata; that pattern is the indicator of compromise for this vulnerability.

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