# Kibana 8.19.22, 9.4.7, 9.5.4 Security Update (ESA-2026-187)

**URL:** <https://discuss.elastic.co/t/kibana-8-19-22-9-4-7-9-5-4-security-update-esa-2026-187/390860>\
**Category:** Security Announcements\
**Created:** [October 6, 2026, 6:36pm UTC](https://discuss.elastic.co/t/kibana-8-19-22-9-4-7-9-5-4-security-update-esa-2026-187/390860 "2026-10-06T18:36:48Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![cronosda](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/cronosda/32/147882_2.png) [@cronosda](https://discuss.elastic.co/u/cronosda)\
**Post date:** [October 6, 2026, 6:36pm UTC](https://discuss.elastic.co/t/kibana-8-19-22-9-4-7-9-5-4-security-update-esa-2026-187/390860/1 "2026-10-06T18:36:48Z")

</div>

**Authorization Bypass Through User-Controlled Key in Kibana Leading to Cross-Tenant Data Interception**

Authorization Bypass Through User-Controlled Key (CWE-639) in Kibana could lead to cross-tenant data interception. In this context, "tenant" refers to a user or team sharing the same Kibana deployment, not a separate Elastic Cloud organization or customer. Kibana's Fleet package installation process allowed a user holding delegated Fleet package-management privileges, without direct Elasticsearch administrative privileges, to claim a data stream identifier already in use by another tenant. Because ownership of that identifier was not verified before Fleet applied the uploaded package's generated index and ingest-pipeline settings to already-existing infrastructure, an attacker could redirect an existing tenant's data stream through infrastructure under their control. This exposed the affected tenant's subsequently ingested data to unauthorized disclosure and modification, and prevented that data from reaching its intended destination. Interception could continue even after the malicious package was removed, requiring separate remediation of the affected infrastructure.

**Affected Versions:**

> - 8.x: All versions from 8.14.0 up to and including 8.19.21
> - 9.x:

- All versions from 9.0.0 up to and including 9.4.6
- All versions from 9.5.0 up to and including 9.5.3

**Affected Configurations:**

> - Kibana deployments with Fleet enabled where a user without full superuser access has been granted the Fleet feature privileges required to install custom (uploaded) integration packages. Both self-managed and Elastic Cloud Hosted deployments are affected.

**Solutions and Mitigations:**

The issue is resolved in versions 8.19.22, 9.4.7, and 9.5.4.

The versions above are the first releases that contain the fix, and later releases also contain it. Elastic recommends upgrading to the most recent release available, and reviewing the [known issues](https://www.elastic.co/docs/release-notes) for your target version before upgrading.

**For Users that Cannot Upgrade:**

**Self-hosted**  
Until upgrading, remove the Fleet feature privileges required to install custom integration packages from any role held by a user who should not be trusted to manage other tenants' data, restricting custom package uploads to full superusers only.

**Cloud**  
The same privilege restriction can be applied on Elastic Cloud Hosted through Kibana role management; no additional cloud-specific limitation is required.

**Indicators of Compromise (IOC)**

Review the installation history of uploaded (non-registry) Fleet packages for any package that declares a dataset already used by a data stream you did not create, and check whether the ingest pipeline governing an existing data stream's backing indices changed as a result of a package installation you did not expect.

**Elastic Cloud Serverless**

Due to our continuous deployment and patching model, the vulnerability described in this security advisory was remediated in our Elastic Cloud Serverless offering before the public disclosure.

**Severity:** CVSSv3.1: High ( 8.8 ) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H  
**CVE ID:** CVE-2026-102406  
**Problem Type:** CWE-639 - Authorization Bypass Through User-Controlled Key