Elastic published fourteen security advisories across Elasticsearch, Kibana and its agent products. The one that stands out is CVE-2026-102406, scored 8.8, in Kibana's Fleet package installation.
It is filed as an authorization bypass through a user-controlled key, which is an accurate and rather dry description of the problem: Fleet let a user name something that already belonged to somebody else, and never checked.
What the flaw is
A user holding delegated Fleet package-management privileges — not an Elasticsearch administrator, just someone allowed to install integrations — could upload a package that claimed a data stream identifier already in use by another tenant.
Fleet did not verify ownership of that identifier before applying the package's generated index and ingest-pipeline settings. And it applied them to infrastructure that already existed, belonging to the other tenant.
The result is that another tenant's data stream can be routed through configuration the attacker wrote. Elastic's own description of the consequences covers all three directions: the data can be disclosed, it can be tampered with, and it can be stopped from reaching where it was meant to go.
Affected versions run up to 8.19.21, 9.4.6 and 9.5.3. The fixes are 8.19.22, 9.4.7 and 9.5.4.
The third consequence is the one that matters
Disclosure and tampering are the obvious harms, and they are the ones a severity score captures.
The third is the interesting one, because of what this product is. Elasticsearch and Kibana are where organisations put their logs — application events, authentication records, network telemetry, the output of their security tooling. A data stream is the pipe that carries it.
An attacker who can redirect that pipe does not only get a copy. They also decide what arrives at the other end. The records that would have shown the intrusion can be read, altered, or simply never delivered — and the dashboards keep rendering, because a data stream that has been quietly re-pointed does not look like an outage.
That is a different class of problem from stealing data. It is a flaw in the instrument you would use to notice you were being attacked.
Deleting the package does not fix it
The detail with the longest tail is in Elastic's own remediation note: the effect persists after the malicious package is removed, and the affected infrastructure needs separate attention.
That follows from how the flaw works. The damage was not done by the package sitting there; it was done by the settings the package wrote onto infrastructure that already existed. Remove the package and those settings stay where they were applied.
We have now written this sentence about three different ecosystems in a fortnight. The npm packages in the MALFEX campaign were pulled from the registry, which does not uninstall them from anyone's machine. GlassWorm's extensions were delisted with the same non-effect. Here the package can be deleted and the redirection survives it.
Removal is a step in remediation. It keeps being mistaken for the whole of it.
What to do
- Upgrade Kibana to 8.19.22, 9.4.7 or 9.5.4, and read the other thirteen advisories rather than only this one.
- Review your Fleet integrations and who installed them. The privilege this needs is delegated package management, which organisations hand out precisely because it is not administrative.
- Check your data streams against their expected index and ingest-pipeline settings. Patching stops new claims; it does not revert one already applied.
- Reconsider who holds delegated Fleet rights. This flaw is a reminder that package installation on a shared observability platform is a privileged operation even when the permission model says otherwise.
What is not established
- Whether it has been exploited. Elastic reports no exploitation.
- How a defender distinguishes a legitimately reconfigured data stream from a hijacked one after the fact.
- Whether a single-tenant deployment is meaningfully exposed, since the described attack turns on crossing a tenant boundary.
- Who found and reported it.
