What is the CVSS score of CVE-2026-49091?

CVE-2026-49091 has a CVSS 3.1 base score of 8.0 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.2%.

Which versions of Kibana are affected by CVE-2026-49091?

Elastic Kibana is vulnerable to log injection attacks that allow manipulation of audit log display through injection of control characters.

How to fix or mitigate CVE-2026-49091?

Within 24 hours: Identify all Kibana instances in production and their current versions. Within 7 days: Prioritize upgrades to Kibana 7.17.15 (for 7.x installations) or 8.11.1 (for 8.x installations); stage patches in non-production environments for testing. Within 30 days: Deploy patches to all production systems and validate log display integrity; review access controls to restrict data submission to trusted sources only.

Kibana CVE-2026-49091

EUVD-2026-41101 HIGH

Improper Encoding or Escaping of Output (CWE-116)

2026-07-01 elastic

GHSA-787j-ggjh-rhm6

Code Injection Elastic Kibana

8.0

CVSS 3.1 · Vendor: elastic

Severity by source

Vendor (elastic) PRIMARY

8.0 HIGH

AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H

vuln.today AI

6.5 MEDIUM

Attacker needs low-privilege input access (PR:L) and an operator to view logs in a vulnerable terminal (UI:R, AC:H); real impact is forging displayed log data (I:H, S:C) with minor confidentiality and no availability effect.

3.1 AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:N

4.0 AV:N/AC:H/AT:N/PR:L/UI:P/VC:L/VI:H/VA:N/SC:L/SI:H/SA:N

Primary rating from Vendor (elastic).

CVSS VectorVendor: elastic

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 01, 2026 - 18:22 vuln.today

DescriptionCVE.org

Improper Output Neutralization for Logs (CWE-117) in Kibana can lead to log injection via Log Injection-Tampering-Forging (CAPEC-93). An attacker can supply specially crafted input that is written to log files without proper neutralization. When the log files are subsequently viewed in a terminal that interprets control sequences, the injected content may alter the displayed log data.

AnalysisAI

Log injection in Elastic Kibana (fixed in 7.17.15 and 8.11.1) allows an attacker with low-privilege access to embed unneutralized control characters in input that Kibana writes verbatim to its log files; when an operator later views those logs in a terminal that interprets ANSI/control sequences, the injected payload can forge, hide, or rewrite displayed log content. The issue is tracked as CWE-117 (Improper Output Neutralization for Logs) and carries a vendor CVSS of 8.0. There is no public exploit identified at time of analysis and it is not listed in CISA KEV.

Technical ContextAI

The root cause is CWE-116/CWE-117: Kibana fails to neutralize (escape or strip) attacker-controlled data before writing it into log files. Log records normally treat their payload as inert text, but many terminal emulators interpret embedded control bytes (e.g., ANSI escape sequences, carriage returns, cursor-movement and screen-clearing codes) at render time. Per CAPEC-93 (Log Injection-Tampering-Forging), an attacker who can get crafted bytes into a logged field can therefore manipulate what a human analyst sees when tailing or catting the log in a terminal, potentially injecting forged entries or masking real ones. The affected component is the Elastic Kibana analytics/visualization front-end for the Elastic Stack (CPE cpe:2.3:a:elastic:kibana), a Node.js application commonly fronting Elasticsearch.

RemediationAI

Upgrade Kibana to a fixed release: Vendor-released patch: 7.17.15 (for the 7.x line) or 8.11.1 (for the 8.x line), per Elastic advisory ESA-2026-53 (https://discuss.elastic.co/t/kibana-7-17-15-8-11-1-security-update-esa-2026-53). Where immediate upgrade is not possible, reduce risk by not viewing raw Kibana log files directly in an interpreting terminal - instead view logs through a log-management/SIEM UI or pipe them through a sanitizer (for example 'cat -v' or 'less -R' disabled / 'less' without raw-control-char passthrough) that renders control bytes literally rather than executing them; the trade-off is slightly less readable output. Additionally, restrict which accounts can supply input to logged fields and who can access the log files, since PR:L means some level of access is a prerequisite. These are compensating controls only; applying the vendor patch is the durable fix.