Kibana Fleet EUVD-2026-58220

The attacker must be authenticated to Kibana with at minimum low-privileged access (PR:L per CVSS), specifically with the ability to create or modify integration policies within Fleet - this is not a default end-user permission and typically requires a Fleet Manager or equivalent role. The vulnerability is only triggered when an integration policy includes optional extra data stream declarations, meaning the attacker must be able to write such a policy and have at least one Elastic Agent enrolled in the corresponding agent policy before the over-privileged API key is issued. Exploitation is limited to write-insert and index-mapping-extension operations on the declared indices - existing documents cannot be read, updated, or deleted, which constrains the data destruction potential. The flaw does not affect deployments where Fleet policy modification is restricted exclusively to fully trusted administrators.

The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N yields a score of 6.5, signaling a meaningful integrity threat with low exploitation complexity over the network, but requiring at least low-privilege authentication (PR:L). The Scope remains Unchanged (S:U), meaning impact is bounded to the Kibana and Elasticsearch instance rather than cascading to external systems. No EPSS score was provided in the available data, and this CVE is not listed in the CISA KEV catalog, so active exploitation in the wild is unconfirmed. No proof-of-concept code has been identified. The real-world risk is elevated primarily in environments where multiple teams or tenants share a Fleet instance with the ability to create or modify integration policies - in those scenarios, a lower-privileged operator could silently gain write access to sensitive or privileged Elasticsearch indices. Single-tenant or tightly access-controlled deployments face reduced risk because the exploit requires a user who already has Fleet integration policy modification rights. The absence of confidentiality and availability impact limits the blast radius, but the High integrity rating is credible: inserting forged documents and extending index mappings can corrupt audit trails, tamper with observability data, or enable downstream pipeline abuse.

An attacker with low-privileged access to a shared Kibana Fleet instance modifies or creates an integration policy, appending extra data stream declarations that target sensitive Elasticsearch indices (e.g., audit logs or security event indices). When Elastic Agents enroll into the corresponding agent policy, Fleet issues them API keys that include write and mapping-extension access to those extra indices. The attacker - or a compromised agent - then uses that over-privileged key to insert fabricated documents into the targeted indices, potentially corrupting audit trails or injecting false telemetry. No public proof-of-concept has been identified, but the steps are straightforward for anyone with Fleet policy access.