Kibana CVE-2026-42401

Exploitation requires two concrete prerequisites: (1) the attacker must hold write access to at least one Elasticsearch index whose data is rendered by a Kibana view - this maps to PR:L in the CVSS vector and is a genuine limiting factor in environments with strict index-level access controls; and (2) a separate victim user must authenticate to Kibana and navigate to a view that renders the injected field value - this maps to UI:R and means fully automated exploitation without victim interaction is not possible. The vulnerability is not limited to a specific non-default configuration: any Kibana instance that renders Elasticsearch field data in the browser without sufficient output encoding is susceptible. What limits exploitation in practice is the requirement for an authenticated write-capable Elasticsearch identity and the dependency on victim navigation. There is no requirement for administrative privilege, special plugin, or non-default feature flag - standard Kibana data visualization functionality is the affected surface.

The CVSS base score of 4.1 (Medium) is consistent with the constrained impact profile: C:N/I:L/A:N means no confidentiality breach and only low integrity impact, though the scope change (S:C) elevates real-world concern by confirming cross-user impact. AV:N/AC:L indicates the exploit is network-reachable with no special access conditions beyond authentication. PR:L confirms a low-privileged Elasticsearch write credential is the entry bar - not anonymous access. UI:R is a genuine limiting factor: a victim must navigate to and render the affected view for exploitation to complete, making mass automated exploitation unlikely. No EPSS score was provided in the source data, preventing quantitative exploitation probability assessment. No CISA KEV listing and no POC exist at time of analysis, suggesting this has not been observed in active threat campaigns. Real-world priority is moderate for multi-tenant or shared Kibana deployments where untrusted low-privilege users can write to indices surfaced in dashboards - in tightly controlled environments where index write access is restricted to trusted operators, practical risk is substantially lower.

An attacker with a low-privilege Elasticsearch account (e.g., a shared reporting user or a compromised service credential) writes a crafted field value containing malicious HTML - such as an image tag with an onerror handler pointing to an attacker-controlled host - into an index that is visualized in a Kibana dashboard. When an administrative or analyst user opens that dashboard, their browser renders the unsanitized value, triggering the injected markup and issuing an outbound request to the attacker's server, potentially carrying session context or enabling further UI redress. No public POC exists at time of analysis, but the attack mechanic is well-understood for stored XSS classes.