New Kibana 0-Day (CVE-2025-68385): Bypassing XSS Defenses via Weaponized Vega Charts

Affiliate Disclosure

Partner Picks 

TL;DR (Executive Summary)

Table of Contents

CVE-2025-68385 is an improper input neutralization vulnerability (CWE-79) in Kibana’s Vega visualization pathway. In plain language: a user who can authenticate to Kibana can embed malicious script payloads into content that is later rendered in other users’ browsers, resulting in cross-site scripting (XSS). The advisory highlights that the exploit path works by bypassing a previous Vega XSS mitigation.

The dangerous part is not that “Kibana has XSS.” The dangerous part is where Kibana sits in enterprises: it is commonly used for SOC dashboards, incident response, threat hunting, reliability observability, and executive reporting. That makes Kibana a privileged surface. XSS here is not cosmetic; it can become session abuse, forced actions, and data exposure.

1. Initial access: attacker has a Kibana-authenticated account (legitimate user, compromised credentials, or a service account exposed through weak SSO controls).
2. Payload planting: attacker creates or edits a Vega visualization and embeds malicious content crafted to bypass prior sanitization.
3. Persistence: visualization is saved as a saved object and placed into dashboards, shared spaces, or copied via exports/imports.
4. Trigger: a victim loads a dashboard containing the visualization; payload executes in the Kibana origin context.
5. Post-execution outcomes: session theft, forced Kibana actions, deceptive dashboards, data visibility manipulation, and pivoting via Kibana APIs depending on the victim role.

• Session hijack / identity misuse: XSS can execute as the user in the browser context and abuse their authenticated session.
• Data exposure: dashboards may contain internal hostnames, alerts, incident narratives, customer telemetry, and sensitive logs.
• Monitoring integrity loss: attacker can deceive dashboards, suppress key visual signals, or insert false comfort during incidents.
• Operational disruption: forced actions inside Kibana can break workflows, cause alert fatigue, or degrade SOC confidence.
• Compliance and governance risk: if Kibana output is used as audit evidence, integrity becomes a compliance issue.

Affected versions:

• 7.x: all versions
• 8.x: 8.0.0 through 8.19.8
• 9.x: 9.0.0 through 9.1.8 and 9.2.0 through 9.2.2

Fixed versions: 8.19.9, 9.1.9, 9.2.3

For Elastic Cloud Serverless, Elastic indicates the vulnerability was remediated before public disclosure due to continuous deployment. Still, confirm your deployment posture and feature usage.

Answer these with evidence, not guesses:

• Is Vega enabled? If yes, treat risk as active until patched or disabled.
• Who can create/edit visualizations? If “many users,” your attack surface is broad.
• Is Kibana internet-exposed? If yes, assume credential attacks are constant and this becomes a fast exploitation path after account compromise.
• Do analysts/admins use Kibana daily? If yes, XSS becomes high impact.
• Do you log saved object operations? If no, you have weak detection/forensics for planted payloads.

This is a vulnerability-driven risk. There is no guaranteed “campaign IOC” (domains/hashes) unless an actor is observed exploiting it. For CVE-2025-68385, the most actionable IOC set is: content indicators (suspicious strings in Vega specs) and behavior indicators (unexpected creation/edit patterns).

6.1 Kibana audit log rule (high value if audit logging is enabled)

Title: Suspicious Vega visualization creation/modification (CVE-2025-68385 hunting)

Data source:
  Kibana audit logs (saved_objects / visualization / dashboard events)
  Optional: reverse proxy/WAF logs for write endpoints

Alert when (ALL of the following recommended):
  1) action indicates saved object create OR update
  2) object type includes visualization (prioritize Vega)
  3) user role is not expected to create visualizations (viewer/analyst-only roles)
  4) change payload contains suspicious XSS primitives (case-insensitive):
     - "<script"
     - "javascript:"
     - "onerror="
     - "onload="
     - "data:text/html"
     - "data:application/xhtml+xml"
     - "eval("
     - "Function("
     - "document.cookie"
     - "localStorage"
     - "sessionStorage"
     - "fetch("
     - "XMLHttpRequest"
     - "navigator.sendBeacon"

Severity:
  High (because Kibana is a privileged console)

Triage steps:
  A) Identify user, source IP, user agent, auth method (SSO/local)
  B) Pull the saved object payload (export or API retrieval)
  C) Find dashboards/spaces where the visualization is embedded
  D) Identify who viewed the dashboard after the change
  E) If malicious content confirmed: disable Vega immediately, invalidate sessions, rotate credentials if required

6.2 Behavior indicators to hunt (even without explicit payload strings)

• Unexpected visualization edits outside business hours.
• Non-admin users creating Vega visualizations for the first time.
• Spikes in saved object updates (visualizations/dashboards) correlated with new user sessions.
• Dashboards that suddenly “behave weirdly” according to analysts (unexpected popups, redirects, auto-refresh loops, unexpected requests).

Your best wins come from: (1) saved object change monitoring, (2) strict RBAC, (3) gateway controls on write endpoints, (4) CSP/browser telemetry where feasible.

7.1 Elastic (KQL) concept query: suspicious strings in Kibana audit logs

// Adjust field names to your audit log schema
event.dataset: "kibana.audit" and
(message:("*vega*" or "*vis_type_vega*") and
 (message:("*<script*" or "*javascript:*" or "*onerror=*" or "*onload=*" or "*data:text/html*" or "*eval(*" or "*Function(*" or "*document.cookie*" or "*sendBeacon*")))

7.2 Splunk SPL concept query (audit logs or proxy logs)

index=kibana_audit (vega OR vis_type_vega OR visualization)
("<script" OR "javascript:" OR "onerror=" OR "onload=" OR "data:text/html" OR "eval(" OR "Function(" OR "document.cookie" OR "sendBeacon")
| stats count min(_time) as firstSeen max(_time) as lastSeen values(user) values(src_ip) values(action) values(object_type) by host
| sort -count

7.3 Reverse proxy / WAF detection idea (protect write paths)

7.4 Endpoint/browser telemetry signals (for high-security SOCs)

• Browser security telemetry showing script execution attempts on Kibana origin.
• CSP violation reports (if configured) indicating blocked inline scripts or suspicious sources.
• Unusual outbound calls from analyst browsers immediately after loading Kibana dashboards.

7.5 Detection note on “PR:N” in CNA scoring

Elastic’s CVSS vector lists PR:N/UI:N with scope changed. In operational terms, do not debate the scoring in meetings. Focus on control: patch, disable Vega if needed, and instrument visibility.

The objective is simple: identify whether anyone has already planted a malicious Vega visualization. Your hunting approach should be: (1) identify Vega visualizations, (2) review who modified them and when, (3) scan their JSON for suspicious primitives, (4) map dashboards that embed them, (5) identify viewers after the change window.

8.1 Practical checklist

• Export or list saved objects (visualizations) and filter for Vega usage.
• Review last-modified metadata and author identity.
• Scan visualization payloads for suspicious strings (see 6.1 list).
• Map dashboards/spaces where the visualization appears.
• Correlate view access logs (or SSO logs) to identify who loaded the dashboard.

8.2 SOC-safe string scan examples (defensive use only)

// Use in a controlled export folder containing saved object JSON exports
// Scan for suspicious tokens commonly used in XSS payloads
grep -Rni -- "vis_type_vega\|\"vega\"\|<script\|javascript:\|onerror=\|onload=\|data:text/html\|eval(\|Function(\|document.cookie\|sendBeacon" ./exported_saved_objects/

9.1 SOC triage runbook (when you detect suspicious Vega activity)

1. Confirm exposure: verify Kibana version is within affected ranges and whether Vega is enabled.
2. Contain immediately: if patch cannot be applied now, disable Vega (vis_type_vega.enabled: false) as an emergency control.
3. Preserve evidence: export saved object(s), capture audit logs, proxy logs, and SSO logs around the change window.
4. Blast-radius mapping: identify dashboards/spaces that embed the visualization, then identify viewers after modification time.
5. Session response: invalidate sessions for impacted users, force re-authentication, and consider credential resets for the author account if compromise is suspected.
6. Eradication: remove or replace malicious visualizations; validate there are no clones in other spaces.
7. Recovery: upgrade to fixed versions, re-enable Vega only after patch and after a saved objects integrity sweep.
8. Lessons learned: tighten RBAC, enable audit logging, add approval workflow for “shared dashboards,” and implement change alerts.

9.2 30–60–90 day plan

• Patch SLAs for privileged consoles: treat Kibana like an admin plane, not a “reporting tool.”
• Least privilege by default: most users should not be able to create or edit Vega visualizations.
• Spaces separation: isolate executive dashboards and SOC dashboards into restricted spaces with tight write controls.
• Network segmentation: restrict Kibana administration access behind VPN/Zero Trust; avoid internet exposure.
• Audit logging: enable and centralize Kibana audit logs; alert on saved object writes.
• Change control for shared dashboards: treat shared dashboards like production artifacts, not personal workspace assets.
• Incident muscle memory: document feature kill-switches (like Vega disable) and rehearse fast response.

Use this framing for leadership updates:

• What happened: Kibana has a high-severity XSS issue in Vega visualizations that can allow malicious content to execute in users’ browsers.
• Why it matters: Kibana is used by SOC and operations; compromise can expose sensitive telemetry and enable session abuse.
• What we’re doing: patching to fixed versions immediately; disabling Vega as an emergency mitigation if needed; monitoring saved object changes.
• What we need: fast change window approval, temporary restrictions on dashboard editing, and verification of audit logging coverage.

If Kibana is part of your SOC, observability, or incident response workflows, CyberDudeBivash can help you harden it as a privileged platform:

• Elastic Stack security assessment (Kibana hardening, RBAC, audit logging, proxy controls)
• Detection engineering (KQL/Splunk rules, saved object integrity monitoring)
• DevSecOps controls for observability pipelines
• Enterprise incident response playbooks for console-layer attacks (XSS/session abuse)

Apps & Products hub: https://www.cyberdudebivash.com/apps-products/
Consulting contact: https://www.cyberdudebivash.com/contact

Q1: If Kibana is internal-only, is this low risk?
Internal-only reduces exposure but does not eliminate risk. XSS is most dangerous when it targets privileged users inside the console.

Q2: What is the fastest safe mitigation?
Upgrade to fixed versions (8.19.9 / 9.1.9 / 9.2.3). If you cannot upgrade immediately, disable Vega using vis_type_vega.enabled: false.

Q3: Do we need to wipe all dashboards?
Not automatically. First: patch/disable Vega, then hunt for suspicious Vega objects and any abnormal edits. Remove malicious items if found.

Q4: Why focus so much on audit logs?
Because planted payloads are saved-object problems. If you cannot see who changed what and when, you are blind to persistence inside Kibana.

• Elastic Security Advisory (ESA-2025-34) – CVE-2025-68385
• NVD – CVE-2025-68385
• Red Hat – CVE-2025-68385
• GitHub Advisory – GHSA-x89f-99hf-gmr7