Kibana CVE-2026-49088

The optional APM (Application Performance Monitoring) instrumentation feature must be explicitly enabled in the Kibana configuration - this is not a default setting. Exploitation is further limited to individuals who already hold operator-level access to the host filesystem or log aggregation system where Kibana application logs are stored. No remote unauthenticated exploitation path exists; this is entirely a passive information disclosure to privileged insiders. Limiting factors include: APM must be opted into, log access is typically restricted to administrators, and the exposed data is only present in logs generated during periods when APM was active.

The NVD CVSS score of 4.4 (Medium) with vector AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N is well-calibrated for this vulnerability. AC:H correctly reflects that APM instrumentation must be enabled (a non-default, explicitly configured feature), and PR:H reflects that exploitation requires an operator already possessing log read access - a significant gating condition. Despite the C:H rating, the practical threat model is narrow: the 'attacker' is an insider or compromised operator account who could likely access sensitive data through other means anyway. There is no EPSS score available in the provided data, no CISA KEV listing, and no identified public proof-of-concept. The real-world risk is primarily an internal defense-in-depth concern - credentials or tokens that should be ephemeral become persistently logged, widening the exposure window beyond the original request lifetime. This is a priority for organizations with strict secrets-management or log-access audit requirements but is a lower operational priority for most teams compared to remotely exploitable vulnerabilities.

An operator or system administrator with read access to Kibana application logs searches log files generated while APM instrumentation was active, locating entries that contain raw HTTP request headers from user or API sessions. The operator extracts Authorization header values or API keys from these log entries and uses them to authenticate as other users or services, enabling lateral movement within the Elastic Stack or connected systems. No exploit code or active network manipulation is required - the sensitive data is passively collected by the APM subsystem during normal operation.