Elastic Stack security update covers CVE-2026-102406 and CVE-2026-103007

What happened

On 6 October 2026 Elastic published two Security Announcements for the Stack releases 8.19.22, 9.4.7, and 9.5.4. ESA-2026-187 assigns CVE-2026-102406 to Kibana: an authorization bypass through a user-controlled key (CWE-639) in Fleet custom-package installation that can redirect another tenant’s data stream. ESA-2026-197 assigns CVE-2026-103007 to Elasticsearch: incorrect authorization (CWE-863) in the non-default manage_roles delegated privilege that can escalate to restricted indices and full cluster administration. Elastic scores the Kibana issue CVSS 3.1 8.8 and the Elasticsearch issue CVSS 3.1 7.2. NVD received both records the same day. Those two CVEs are the high-severity pair in this announcement wave; other Elastic ESAs published around the same release train address separate medium denial-of-service issues and are not recorded as additional ThreatWire cards here.

Who is affected

Kibana operators on 8.14.0–8.19.21, 9.0.0–9.4.6, or 9.5.0–9.5.3 with Fleet enabled and custom uploaded-package install privileges granted to non-superusers are in scope for CVE-2026-102406. Both self-managed and Elastic Cloud Hosted deployments can be affected. Elasticsearch operators on 8.16.0–8.19.21, 9.0.0–9.4.6, or 9.5.0–9.5.3 are in scope for CVE-2026-103007 only when manage_roles uses wildcard or regex index patterns that can match restricted or system indices. Elastic says Serverless is outside CVE-2026-103007 because the feature is unavailable there, and that Serverless already received continuous remediation for the Kibana issue before public disclosure.

What is confirmed

For CVE-2026-102406, Elastic confirms that Fleet did not verify ownership of an existing data-stream identifier before applying an uploaded package’s index and ingest-pipeline settings, enabling cross-tenant intercept and modification of subsequently ingested data on a shared Kibana deployment. For CVE-2026-103007, Elastic confirms that scoping checks for manage_roles fail to account for a role-definition setting that expands matched indices, so a holder with a broad pattern can widen their own role toward internal security data and full admin. GitHub advisories GHSA-gpr2-2mpc-hvf2 and GHSA-5jrv-cmh5-3vmg mirror the vendor CVSS scores. Neither CVE is in CISA KEV. CISA SSVC sets exploitation to none for both.

What is not confirmed

Active exploitation is not confirmed. No public proof-of-concept repository matching either CVE id was found at drafting time, so ThreatWire leaves availability at none and does not attach a PoC URL. Social posts that imply every Elastic install is immediately exploitable without Fleet custom-package privileges or without manage_roles wildcards overstate Elastic’s affected-configuration text.

What to do

Upgrade Kibana and Elasticsearch to 8.19.22, 9.4.7, or 9.5.4 (or a later release Elastic verifies as fixed). Until then, restrict Fleet custom-package installation to full superusers for the Kibana issue, and for Elasticsearch review manage_roles grants so index names are literal only—or remove the privilege from untrusted users—then audit roles created through that path. After upgrading, review Fleet uploaded-package history and unexpected ingest-pipeline changes for CVE-2026-102406, and review audit logs for role changes by manage_roles holders for CVE-2026-103007.

Sources: Elastic ESA-2026-187 and ESA-2026-197, NVD and CVE.org for both CVE ids, and GHSA-gpr2-2mpc-hvf2 and GHSA-5jrv-cmh5-3vmg.