Kibana EUVD-2026-93927

Requires a multi-tenant Kibana deployment where tenants (users/teams) share one deployment, and an authenticated actor who holds delegated Fleet package-management privileges but lacks direct Elasticsearch administrative privileges. The attacker must be able to identify and claim a data stream identifier already in use by another tenant and upload a Fleet package whose generated index and ingest-pipeline settings are then applied to that pre-existing infrastructure without an ownership check. Limiting factors: exploitation is impossible in single-tenant deployments or where the Fleet package-management privilege is not delegated to untrusted users; it requires valid authenticated access (PR:L), not anonymous access. Note persistence - interception can continue after the malicious package is removed, so the affected data-stream infrastructure must be separately remediated.

This is a credible, action-worthy priority rather than an inflated high-CVSS artifact, but its real-world reach is gated by deployment model. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) and the 8.8 score reflect a network-reachable, low-complexity flaw needing only low privileges and no user interaction, with full C:H/I:H/A:H impact - consistent with the described cross-tenant interception, tampering, and data-flow disruption. Per the precision rules, PR:L confirms this requires an authenticated actor (specifically a holder of delegated Fleet package-management privileges), so it is NOT unauthenticated internet-spray material; it is an insider or compromised-low-privilege-account scenario within a shared Kibana deployment. Exploitation status: no public exploit identified at time of analysis - there is no KEV listing and no POC referenced in the provided data. No EPSS score and no SSVC decision data were supplied, so automatability and exploitation-maturity signals cannot be weighed - treat probabilistic exploitation likelihood as UNKNOWN. The signals are internally consistent (the CWE-639 user-controlled-key authorization bypass matches the AV:N/PR:L framing), so there is no CVSS-versus-description conflict to flag; the main caveat is that impact severity assumes a genuinely multi-tenant Kibana deployment, which not all installations are.

In a shared multi-tenant Kibana deployment, an authenticated user holding only delegated Fleet package-management privileges (no Elasticsearch admin) uploads a crafted Fleet package that claims a data stream identifier already owned by another tenant. Because Fleet does not verify ownership before applying the package's generated index and ingest-pipeline settings to the existing infrastructure, the victim tenant's subsequently ingested data is redirected through attacker-controlled infrastructure, enabling disclosure and modification and blocking delivery to its intended destination. No public exploit identified at time of analysis.