Kibana Fleet CVE-2026-49095

Exploitation requires an authenticated Kibana session with the Fleet management privilege (CVSS PR:H), the Fleet feature must be enabled on the Kibana deployment, and the attacker must be able to create or modify an agent policy so that the unvalidated configuration override field is processed. No user interaction from another user is required (UI:N) and the attack is network-reachable to the Kibana API (AV:N/AC:L). Limiting factors are the high-privilege prerequisite - environments where Fleet roles are assigned only to administrators already trusted with Elasticsearch security indices gain little additional risk - and the requirement that Fleet be in use at all; pure Kibana visualization deployments without Fleet are not exposed.

The CVSS 3.1 vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N scores 7.2 and reflects a realistic profile: network-reachable, low complexity, no user interaction, but requires high privileges (a Fleet management role) and yields high confidentiality and integrity impact with no availability impact. EPSS data was not provided in the input, KEV status is not listed, and no public exploit code has been identified at time of analysis, so this is not yet an opportunistic mass-exploitation target. The real risk is insider-style or post-compromise escalation: any user already granted Fleet privileges - a role often delegated more loosely than full superuser - can pivot into Elasticsearch security indices, which typically store authentication artifacts and audit data. Organizations that treat the Fleet role as low-trust ('just manages agents') are likely the most exposed; the gap between intended trust and actual blast radius is what makes this material despite the PR:H requirement.

A user holding the Kibana Fleet management role - for example, a junior SRE delegated agent lifecycle duties - opens or updates an agent policy and supplies crafted values in the configuration override fields that Fleet does not adequately validate. Kibana issues the affected Elastic Agents API keys carrying broader Elasticsearch privileges than the Fleet role should be able to grant, and the attacker then uses those keys (or pivots through a compromised agent host) to read or modify Elasticsearch security indices containing credentials, role mappings, and audit data. No public proof-of-concept has been published at time of analysis.