CVE-2025-65110 is a high severity cross-site scripting flaw in the Vega visualization library, scored CVSS 8.1. Script can run even in safe expression mode when two conditions hold. Upgrade vega-selections to 6.1.2 on Vega 6 or 5.6.3 on Vega 5.
What's affected
The GitHub advisory lists the package vega-selections on npm. Affected versions are 6.1.0 and earlier and 5.6.1 and earlier. Patched versions are 6.1.2 and 5.6.3. The NVD record describes the fixed releases as Vega 6.1.2 and 5.6.3, so check both the vega and the vega-selections versions in your lock file.
With Vega 6, use vega-selections 6.1.2, which requires ES modules. With Vega 5, use vega-selections 5.6.3, which needs no ESM. The advisory was published on 5 January 2026.
Two conditions must both hold for an application to be at risk. First, it attaches the vega library and a vega.View instance to the global window object, as the Vega Editor did, or it has some other helpful functions in global scope. Second, it accepts user supplied Vega JSON definitions instead of definitions that come only from your source code.
How to check if you're exposed
List the Vega packages in each project.
npm ls vega vega-selections vega-lite
pnpm why vega-selections
Vega Lite brings in Vega packages, so check it even if you never named vega directly. Compare vega-selections with 6.1.2 for Vega 6 or 5.6.3 for Vega 5.
Then test your exposure against the two conditions. Search your code for places where a vega object or a View is stored on window or another global, which is sometimes done for debugging. And ask whether any user can supply or edit a chart definition that your application then renders. If you only render charts whose specifications you wrote, the second condition is not met.
What to do now
- Find all projects that depend on vega, vega-lite or vega-selections.
- Upgrade vega-selections to 6.1.2 or 5.6.3, matching your Vega major version.
- On Vega 6, confirm your bundler handles ES modules, since 6.1.2 requires them.
- Remove code that attaches vega or View objects to window. The advisory calls this a development only practice that should never run where untrusted parties can supply definitions.
- If you let users supply chart specs, validate them against an allow list of features and render them in a sandboxed frame.
- Add a Content Security Policy that blocks inline script, to limit the effect of any script that does run.
Why it matters
The class is CWE-79, cross-site scripting. Vega lets chart authors write small expressions, and its safe mode is meant to block arbitrary function calls. The advisory explains that when an event is passed into an expression, objects reachable from the window can be read. In an environment that exposes helpful functions globally, a crafted definition can chain existing functions together to reach script execution without calling anything forbidden directly.
This is a good example of a gadget style problem. Nothing in the library is broken alone: it is the combination of the library's reach, the page's globals and untrusted input. The workaround, removing the globals, makes the point. The fewer powerful objects that sit in global scope, the fewer chains an attacker can build from them.
The two conditions also show why reachability analysis matters. Many applications that depend on Vega never accept user written specs, so the flaw is present in their dependency tree but not reachable. Knowing which applications fit both conditions lets you spend upgrade time first where it counts. The KEV flag is false.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does safe mode protect me?
Not under the two conditions in the advisory. The advisory states code execution is possible even when the safe expression interpreter is used.
I only render my own charts. Am I affected?
The advisory's second condition is that you allow user defined Vega JSON. If specs come only from your own source code, the described attack does not apply, but you should still upgrade.
Sources
Last reviewed: 19 October 2026.
