Brief Summary: Kibana CVE-2026-42398 SSRF Allowlist Bypass via Webhook Connector

Introduction

CVE-2026-42398 is the third Server-Side Request Forgery vulnerability disclosed in Elastic's Kibana in 2026. This one defeats the egress control that operators deploy to restrict where Kibana can send outbound requests. For organizations that deliberately configured xpack.actions.allowedHosts as a security boundary, any authenticated user with connector management privileges can bypass that boundary and use Kibana as a proxy to reach internal services that were supposed to be off limits.

The vulnerability has a CVSS score of 7.7 (High), driven mainly by the "Scope: Changed" designation, which means the impact extends past Kibana to the network resources the allowlist was designed to protect. There are no workarounds. The only remediation is to upgrade to Kibana 9.2.8 or 9.3.2.

Technical Information

Root Cause: Allowlist Validation Bypass in Webhook Connectors

CVE-2026-42398 is classified under CWE-918 (Server-Side Request Forgery), which OWASP elevated to the Top 10 in 2021 as A10:2021 because of its increasing prevalence in modern web applications. The bug is in Kibana's Webhook connector feature, which lets users configure outbound HTTP integrations to external services.

Kibana has an operator-level setting, xpack.actions.allowedHosts, that is an allowlist of permitted outbound destinations for connectors. When it is set to anything other than the wildcard *, it is supposed to enforce egress restrictions and stop connectors from contacting unauthorized hosts. CVE-2026-42398 lets an authenticated user craft a Webhook connector target that gets around this validation logic entirely.

CVSS Vector Analysis

The full CVSS v3.1 vector is AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, which breaks down as follows:

The "Scope: Changed" designation is the most important part of this vector. It means the impact reaches past the vulnerable component (Kibana) into a different security scope, in this case the internal network services and endpoints that xpack.actions.allowedHosts was configured to protect.

Attack Flow

Exploitation has four stages:

1. The attacker authenticates to Kibana with credentials that grant connector management privileges. This could be a legitimate insider, a compromised account, or a user who has escalated privileges through another vulnerability.

2. The attacker creates or modifies a Webhook connector and gives it a crafted target URL designed to bypass the allowlist validation logic. The public advisory does not describe the bypass technique, which is consistent with Elastic's responsible disclosure practices.

3. When the connector runs, Kibana sends an outbound HTTP request to the crafted destination. The allowlist check has been bypassed, so the request reaches a host the operator intended to block.

4. The attacker receives the response from the restricted destination. This can expose information from internal services, cloud metadata endpoints (such as http://169.254.169.254/ for AWS IMDSv1), Elasticsearch clusters, or other network-segmented resources.

The vulnerability is exploitable only when xpack.actions.allowedHosts is actively configured to restrict connections. Deployments that use the wildcard * have no allowlist boundary to bypass, though unrestricted outbound access carries its own SSRF-related risks.

Known SSRF Bypass Techniques

The exact bypass method in CVE-2026-42398 has not been publicly disclosed, but OWASP and security researchers have documented several common ways attackers get around SSRF allowlist protections:

• URL parser inconsistencies: Programming languages and libraries do not all parse URLs the same way. A URL that passes validation in one parser can be interpreted differently by the HTTP client, which slips it past the allowlist check.
• DNS rebinding: A TOCTOU (time-of-check, time-of-use) attack. The attacker controls a domain that resolves to an allowed IP address during validation, then switches to an internal IP address when the real request is made.
• Open redirect chaining: An open redirector on a trusted domain forwards the request from an initially allowed destination to an internal resource. Tools like r3dir enable this kind of bypass.

Scope Considerations

Kibana is typically deployed with direct access to Elasticsearch clusters, which may hold sensitive log data, security event information, and business-critical indices. A successful SSRF from Kibana could let an attacker run reconnaissance against these internal services, reach cloud provider metadata APIs, or interact with other internal services that trust requests coming from the Kibana server's IP address.

Affected Systems and Versions

The following Kibana versions are confirmed vulnerable:

The vulnerability affects only deployments where xpack.actions.allowedHosts is configured to restrict outbound connections (not set to the wildcard *). Elastic Cloud Serverless deployments were remediated automatically through standard patching processes before public disclosure and need no manual action.

The advisory documents no configuration-based workaround. Upgrading to a patched version is the only remediation.

Defense-in-Depth Recommendations

Patching is the only fix, but organizations can apply OWASP-recommended SSRF defense-in-depth measures to reduce risk:

1. Network segmentation: Do not give Kibana servers unrestricted access to sensitive internal network segments. Put remote resource access functionality on separate networks to limit the blast radius of a successful SSRF.
2. Deny-by-default firewall policies: Block all traffic to and from Kibana except what is essential. Log both accepted and blocked network flows so anomalous outbound requests show up.
3. Restrict connector management privileges: Grant them to as few users as necessary. Fewer accounts with this privilege means fewer potential attackers.
4. Monitor audit logs: Review Kibana audit logs for Webhook connector creation and modification events, especially connectors aimed at unusual or internal destinations. The ESA-2026-28 advisory for a related Kibana SSRF has detection guidance that applies here. It says to focus on HTTP step executions that follow redirects and to watch network egress traffic for connections to unexpected internal destinations.
5. Disable HTTP redirections: Prevent Kibana from following HTTP redirects at the network level, since redirects can be used in SSRF chain attacks.

Vendor Security History

Elastic has published at least eight security advisories for Kibana in the first five months of 2026, and four of them address SSRF vulnerabilities:

Here are the SSRF advisories on their own:

The same class of bug keeps appearing in different connector and workflow subsystems, which suggests that the URL validation and allowlist enforcement logic shares common design weaknesses. Point patches close individual bypass techniques. Given what these vulnerabilities have in common architecturally, it is fair to ask whether Kibana's outbound request handling needs a more fundamental redesign. Organizations should not assume that patching this one CVE fully addresses the SSRF risk in Kibana, and should watch closely for future advisories.

Elastic is a CVE Numbering Authority (CNA) and runs a consistent disclosure and patching process through its product security team and the security announcements on its community forum. The high frequency of advisories shows active security maintenance. It also shows that Kibana's attack surface, particularly around connectors and workflows, remains a persistent source of vulnerabilities.

References

• NVD: CVE-2026-42398
• Elastic Security Advisory ESA-2026-37: Kibana 9.2.8 and 9.3.2 Security Update
• NVD: CVE-2026-33458 (Related Kibana SSRF)
• Elastic Security Advisory ESA-2026-17: Kibana 9.3.1 Security Update
• Elastic Security Advisory ESA-2026-05: Kibana Security Update
• Elastic Security Advisory ESA-2026-28: Kibana 9.3.3 Security Update
• Elastic Security Announcements
• Product Security at Elastic
• OWASP A10:2021 Server-Side Request Forgery
• OWASP SSRF Prevention Cheat Sheet
• Bypassing SSRF Filters Using r3dir (Leviathan Security)
• Elastic CVEs and Security Vulnerabilities (OpenCVE)
• SentinelOne: CVE-2026-33458 Kibana One Workflow SSRF