CVE-2026-49088: Kibana sensitive headers leaked

CISO Take

This is a straightforward information-disclosure bug in Kibana: when the optional Application Performance Monitoring (APM) instrumentation is turned on, request header values — potentially including Authorization tokens or API keys — get written into application logs instead of being redacted. It's rated only medium (CVSS 4.4) because exploitation requires an attacker to already hold high privileges (PR:H) and complex conditions (AC:H) to reach the log data, there's no EPSS score published, it's not in CISA KEV, and no public exploit or scanner template exists — this is a log-hygiene issue, not an actively exploited flaw. The real risk is indirect: any credentials that transit instrumented requests (including LLM/API gateway tokens if Kibana sits in front of AI service traffic) become visible to anyone with log access, which is a broader blast radius than the CVSS score implies given how permissive log-viewer roles often are. Action: patch to Kibana 8.18.9, 8.19.6, 9.0.8, or 9.1.6 per the Elastic advisory, disable APM instrumentation until patched if you can't upgrade immediately, and audit/rotate any tokens that may have already been logged.

Sources: NVD discuss.elastic.co

What is the risk?

Low-to-medium operational risk. The CVSS vector (AC:H, PR:H, S:U, C:H/I:N/A:N) means an attacker needs high privileges and non-trivial conditions to trigger the disclosure, and impact is confidentiality-only — no integrity or availability effect. There is no evidence of active exploitation (not in CISA KEV, no EPSS percentile, no public PoC or Nuclei template), so this is best treated as a hygiene/compliance finding rather than an urgent incident. The bigger risk driver is organizational: over-broad access to log infrastructure (common in ops/SRE teams) turns a 'high privilege required' bug into something reachable by many people who were never meant to see secrets.

How does the attack unfold?

Privileged log access

Attacker holds or obtains a high-privilege account (PR:H) with read access to Kibana's application/APM logs.

APM header capture

With APM instrumentation enabled, incoming request header values (e.g., Authorization tokens) are recorded verbatim into application logs instead of being redacted.

Header harvesting

The attacker searches or exports the affected logs to extract sensitive header values such as bearer tokens or session cookies.

Credential reuse

Harvested tokens are replayed against the originating API (potentially an AI/LLM service or internal gateway) to gain unauthorized access or exfiltrate data.

Privileged log access

Attacker holds or obtains a high-privilege account (PR:H) with read access to Kibana's application/APM logs.

APM header capture

With APM instrumentation enabled, incoming request header values (e.g., Authorization tokens) are recorded verbatim into application logs instead of being redacted.

Header harvesting

The attacker searches or exports the affected logs to extract sensitive header values such as bearer tokens or session cookies.

Credential reuse

Harvested tokens are replayed against the originating API (potentially an AI/LLM service or internal gateway) to gain unauthorized access or exfiltrate data.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Kibana	—	—	No patch

Do you use Kibana? You're affected.

How severe is it?

CVSS 3.1

4.4 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 12% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC High

PR High

UI None

S Unchanged

C High

I None

A None

What should I do?

1 step

Upgrade Kibana to a patched release (8.18.9, 8.19.6, 9.0.8, or 9.1.6) as listed in the Elastic advisory ESA-2026-50. If immediate patching isn't possible, disable APM instrumentation or configure header redaction/sanitization for sensitive fields (Authorization, Cookie, API-Key) before upgrading. Apply least-privilege access controls to log storage and log-viewing roles so 'PR:H' in practice maps to a genuinely small set of trusted operators. Audit historical APM/application logs for exposed header values and rotate any credentials (including AI service/API keys) that may have been captured. Add detection for anomalous log-export or log-search activity by accounts with log-viewer roles.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Leakage Privacy Violation API

Which compliance frameworks are affected?

This CVE is relevant to:

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-49088?

This is a straightforward information-disclosure bug in Kibana: when the optional Application Performance Monitoring (APM) instrumentation is turned on, request header values — potentially including Authorization tokens or API keys — get written into application logs instead of being redacted. It's rated only medium (CVSS 4.4) because exploitation requires an attacker to already hold high privileges (PR:H) and complex conditions (AC:H) to reach the log data, there's no EPSS score published, it's not in CISA KEV, and no public exploit or scanner template exists — this is a log-hygiene issue, not an actively exploited flaw. The real risk is indirect: any credentials that transit instrumented requests (including LLM/API gateway tokens if Kibana sits in front of AI service traffic) become visible to anyone with log access, which is a broader blast radius than the CVSS score implies given how permissive log-viewer roles often are. Action: patch to Kibana 8.18.9, 8.19.6, 9.0.8, or 9.1.6 per the Elastic advisory, disable APM instrumentation until patched if you can't upgrade immediately, and audit/rotate any tokens that may have already been logged.

Is CVE-2026-49088 actively exploited?

No confirmed active exploitation of CVE-2026-49088 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-49088?

Upgrade Kibana to a patched release (8.18.9, 8.19.6, 9.0.8, or 9.1.6) as listed in the Elastic advisory ESA-2026-50. If immediate patching isn't possible, disable APM instrumentation or configure header redaction/sanitization for sensitive fields (Authorization, Cookie, API-Key) before upgrading. Apply least-privilege access controls to log storage and log-viewing roles so 'PR:H' in practice maps to a genuinely small set of trusted operators. Audit historical APM/application logs for exposed header values and rotate any credentials (including AI service/API keys) that may have been captured. Add detection for anomalous log-export or log-search activity by accounts with log-viewer roles.

What systems are affected by CVE-2026-49088?

This vulnerability affects the following AI/ML architecture patterns: Observability/logging pipelines fronting AI API gateways, AI service monitoring via APM instrumentation.

What is the CVSS score for CVE-2026-49088?

CVE-2026-49088 has a CVSS v3.1 base score of 4.4 (MEDIUM). The EPSS exploitation probability is 0.21%.

What is the AI security impact?

Affected AI Architectures

Observability/logging pipelines fronting AI API gatewaysAI service monitoring via APM instrumentation

Compliance Controls Affected

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

Insertion of Sensitive Information into Log File (CWE-532) in Kibana can lead to information disclosure. When the optional application performance monitoring (APM) instrumentation is enabled, sensitive request header values could be recorded in application logs, where they may be accessible to operators with log access.

Exploitation Scenario

An organization runs Kibana with APM instrumentation enabled to trace requests across services, including an internal API gateway that proxies calls to an LLM provider. A user with high-privilege log access — either a legitimate operator misusing their access or an attacker who has already compromised such an account — searches or exports the APM logs and finds Authorization header values (bearer tokens for the LLM API, session cookies, or internal service credentials) that were captured verbatim instead of being redacted. The attacker reuses the harvested token to call the LLM API or downstream service directly, bypassing normal authentication controls and potentially incurring cost, exfiltrating data, or pivoting further into the environment.

Weaknesses (CWE)

CWE-532 Insertion of Sensitive Information into Log File

CWE-532 — Insertion of Sensitive Information into Log File: The product writes sensitive information to a log file.

[Architecture and Design, Implementation] Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files.
[Distribution] Remove debug log files before deploying the application into production.

Source: MITRE CWE corpus.