Vega Expression Context Leakage Leading to XSS via `setdata`

The Vega visualization grammar allows users to define interactive visualizations using a JSON specification. To support interactivity, Vega includes an expression language that evaluates logic within signal handlers. While Vega implements an expression interpreter to restrict execution to a safe subset of JavaScript, CVE-2025-66648 reveals a bypass in this sandbox mechanism located within the vega-functions component.

The vulnerability manifests in the setdata expression function, which is designed to modify data tuples dynamically. The flaw allows an attacker to manipulate the test predicate argument of the underlying modify function. By traversing properties available on the event object—specifically accessing the internal Dataflow graph and the DOM element—an attacker can reach the global window object. This effectively grants access to native browser APIs (e.g., fetch, alert) and enables arbitrary code execution in the context of the application rendering the chart.

The root cause is a combination of object context leakage and insufficient validation of function arguments within the internal modify() function. When a signal event triggers, Vega exposes an event object to the expression scope. This object inadvertently retains references to internal engine structures that should be opaque to the user.

Specifically, the event object links to the dataflow instance, which in turn holds a reference to the underlying DOM element (_el). From a DOM element, standard JavaScript property traversal allows access to ownerDocument and defaultView, effectively leaking the global window object. The modify(name, insert, remove, toggle, test, values) function failed to validate that its test argument was a safe, internal predicate. Instead, it accepted any function reference passed to it and executed that function against data tuples during the dataflow propagation cycle.

The vulnerability lies in how vega-functions handles arguments passed to the setdata (and underlying modify) function without scrutinizing the origin of the predicate function. Below is a conceptual representation of the vulnerable logic versus the patched approach.

Vulnerable Logic

The unpatched version allowed the test parameter to be any callable function derived from the expression scope, including those reachable via the prototype chain or object traversal.

// Conceptual vulnerable implementation in vega-functions
function modify(name, insert, remove, toggle, test, values) {
  // ... lookup dataset by name ...
  
  // The 'test' function is invoked directly without verifying it is safe
  if (test && test(tuple)) {
    // modify tuple
  }
}

Patched Logic (v6.1.1)

The fix introduces strict validation to ensure arguments are expected types and blocks access to sensitive internal properties like _el on the dataflow object. The patch likely sanitizes the event object before exposing it to the expression scope or explicitly validates that the test function is a generated internal predicate rather than a user-supplied reference to window methods.

// Conceptual patched implementation
function modify(name, insert, remove, toggle, test, values) {
  // Validation: Ensure 'test' is not a native function or external reference
  if (test && !isInternalPredicate(test)) {
     throw new Error("Illegal argument to setdata");
  }
 
  // Hardening: The 'event' object passed to expressions no longer exposes '_el'
  // event.dataflow._el => undefined
}

Exploitation requires the attacker to supply a malicious Vega JSON specification to a target application. The payload leverages a signal handler listening for standard user interaction events (like click or mouseover) to trigger the execution chain.

The attacker constructs a setdata call that walks the property chain from event to window. The payload demonstrates executing alert(), but a real-world attack would likely use fetch() to exfiltrate tokens or eval() (if CSP permits) to execute complex payloads.

Proof of Concept

{
  "$schema": "https://vega.github.io/schema/vega/v5.json",
  "signals": [
    {
      "name": "triggerXSS",
      "on": [
        {
          "events": "click",
          "update": "setdata('table', [], [], [], event.dataflow._el.ownerDocument.defaultView.alert('XSS'))"
        }
      ]
    }
  ],
  "data": [
    { "name": "table", "values": [{"id": 1}] }
  ]
}

> [!WARNING] > CSP Safe Mode Bypass: This vulnerability bypasses vega.expressionInterpreter. Even if an application explicitly uses the interpreter to avoid eval() and adhere to Content Security Policy, this specific vector succeeds because it relies on existing function references (window.alert) rather than string-to-code compilation.

The impact of this vulnerability is high (CVSS 7.2) because it allows for Stored XSS or Reflected XSS depending on how the application loads Vega specifications.

Confidentiality: Attackers can read sensitive data from the DOM, including session cookies (if not HttpOnly), LocalStorage tokens, and CSRF tokens.

Integrity: Attackers can modify the visual content of the dashboard to mislead users or inject phishing forms overlaying the legitimate application interface.

Scope: This affects any system integrating Vega or Vega-Lite where users can save or share visualizations. Common targets include data science notebooks (Jupyter), business intelligence dashboards (Kibana), and wiki-style documentation systems integrating Vega rendering.

The only effective remediation is to upgrade the vulnerable dependencies.

• Component: vega-functions
• Fixed Version: 6.1.1
• Parent Package: vega (Fixed in 5.30.0 or equivalent depending on dependency tree resolution)

Developers should verify their lockfiles (package-lock.json or yarn.lock) to ensure that transitive dependencies of vega are resolved to vega-functions version 6.1.1 or higher. No configuration changes or workarounds are available; the code itself must be patched to prevent the context leakage.