Elastic Kibana EUVD-2026-116074

Two concrete prerequisites must both hold: (1) the attacker is an authenticated Kibana user who has been granted privileges to onboard Observability data (PR:L - not an anonymous or read-only user); and (2) the deployment has embedded the Elasticsearch connection credentials directly inside the Elasticsearch host URLs in the Kibana configuration (e.g. credentials in the elasticsearch.hosts URL rather than in separate username/password settings). This configuration dependency is the primary limiting factor: environments that keep credentials out of the host URL may not expose them via this path. Exploitation does not require user interaction or local access, but it is bounded by the attacker first having a valid Kibana account with onboarding rights, which confines realistic risk largely to insiders or compromised low-privilege accounts rather than the open internet.

This is a moderate, authenticated privilege-escalation-via-disclosure issue rather than a mass-exploitation emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N, C:H/I:N/A:N, score 6.5) is internally consistent with the description: a network-reachable, low-complexity attack that requires an already-authenticated Kibana user (PR:L) holding Observability onboarding privileges, yielding confidentiality impact only (the Elasticsearch service-account credentials) with no direct integrity or availability loss. The real severity is the downstream effect - the disclosed credentials let the user act as the Kibana service account in Elasticsearch, exceeding their granted privileges - but Elastic scored this S:U (no scope change), which understates that escalation; the practical impact depends on how broad the Kibana service account's Elasticsearch privileges are in the target deployment. No EPSS score, no CISA KEV listing, and no public exploit were provided in the input, so there is no signal of active or widespread exploitation; the vendor's own priority label is 'this_month' (not act_now/emergency), consistent with an insider/authorized-user abuse path rather than an internet-facing pre-auth flaw. Key caveat: exploitation is conditional on credentials being embedded in the Elasticsearch host URLs in the Kibana config, so deployments that supply credentials via separate settings may not be exposed - this should be verified against each environment's configuration.

An authenticated Kibana user who has been granted the ability to onboard Observability data uses the onboarding flow, which reflects the Elasticsearch connection string back in a way that exposes the service-account credentials embedded in the configured Elasticsearch host URLs. The user harvests those credentials and connects to Elasticsearch directly, operating with the full privileges of the Kibana service account - well beyond what their own Kibana role permits. No public exploit was identified in the provided data; the attack requires valid Kibana access and low attack complexity.