GHSA-c75x-9x9h-28rm: Npm/@highcharts/grid-pro vulnerability

Published Oct 28, 2026
·
Updated

Impact When a single cell value is written to a data table, the column id is used as a key on the table's column collection without filtering, so a column id of proto resolves to Object.prototype, is taken for an existing column, and the write lands at the row index on Object.prototype; a column id of constructor writes onto the Object constructor in the same way. In Dashboards releases that still supported column aliases, the id is first resolved through the alias map, so a literal proto id is redirected harmlessly there, while an alias whose target is proto, which the connector's data table options accept, reaches the same write. An attacker who controls the column id can thereby set integer-keyed properties on Object.prototype, one per row index, holding the written value; named properties cannot be reached through these paths, because the row index is a number. The integer keys still affect every object in the page: reading an out-of-range index on any array or plain object returns the injected value, and for...in over any object yields the injected keys, so unrelated code can take branches it should not using attacker-supplied data, and rendering can fail as a side effect. In Dashboards the write is reached through the Highcharts component's connector write-back, which is enabled by default through allowConnectorUpdate and takes the column id from the component's columnAssignment, or in the earliest releases from the series name, when a point is updated; in Grid Pro it is reached through cell editing in earlier releases and remains reachable through the public DataTable API. Exploitation requires that untrusted data reach the board or Grid configuration and that a point be updated or a cell edited, or that the application write a cell with an untrusted column id.

Consequences beyond disruption depend on the consuming application.

Workarounds Two measures are needed. The first closes the paths that reach Object.prototype; the second covers table construction, which cannot be patched from outside the library.

1. Strip unsafe keys from untrusted column data

Apply this wherever column data enters your application, before it is handed to a grid, board or DataTable. This is the only measure that covers the DataTable constructor.

js function stripUnsafeColumnIds(columns) { for (const key of ['proto', 'constructor']) { if (Object.prototype.hasOwnProperty.call(columns, key)) { delete columns[key]; } }

return columns; }

Grid.grid('container', { data: { columns: stripUnsafeColumnIds(untrustedColumns) } });

2. Patch the DataTable methods

Needed if your application passes column ids that originate from untrusted input to setCell, changeColumnId or setColumns. Run it once at startup.

js { const { DataTable } = Grid; // Or Dashboards

if (!DataTable) { throw new Error('Patch loaded before Grid'); }

const unsafe = (id) => id === 'proto' || id === 'constructor';

const setCell = DataTable.prototype.setCell; DataTable.prototype.setCell = function (columnId, ...rest) { if (unsafe(columnId)) { return; } return setCell.call(this, columnId, ...rest); };

const changeColumnId = DataTable.prototype.changeColumnId; DataTable.prototype.changeColumnId = function (columnId, newColumnId) { if (unsafe(columnId) || unsafe(newColumnId)) { return false; } return changeColumnId.call(this, columnId, newColumnId); };

const setColumns = DataTable.prototype.setColumns; DataTable.prototype.setColumns = function (columns, ...rest) { const safe = {};

for (const key of Object.keys(columns || {})) { if (!unsafe(key)) { safe[key] = columns[key]; } }

return setColumns.call(this, safe, ...rest); }; }

For npm, take DataTable from your import instead of the global — it is exported by Grid Lite, Grid Pro and Dashboards alike.

Obtaining the patched version The patched releases are available from all the usual distribution channels. With npm, upgrade the affected package to the patched version listed above, for example npm install @highcharts/dashboards@4.2.2. If you load Highcharts Dashboards from a CDN, use a versioned URL, for example https://code.highcharts.com/dashboards/4.2.2/dashboards.js. For more on each installation method, see the installation guide.

Affected Software

2 affected componentsFixes available
npm/@highcharts/grid-pro>=2.0.0<=3.1.0
3.2.0
npm/@highcharts/dashboards>=1.0.0<=4.2.1
4.2.2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/@highcharts/grid-pro to a version that resolves this vulnerability.

    Fixed in 3.2.0
  2. Upgrade

    Upgrade npm/@highcharts/dashboards to a version that resolves this vulnerability.

    Fixed in 4.2.2
  3. Upgrade

    Upgrade @highcharts/dashboards to a version that resolves this vulnerability.

    Fixed in 4.2.2
  4. Compensating control

    Patch DataTable.prototype.changeColumnId, DataTable.prototype.setCell, and DataTable.prototype.setColumns at application startup to reject columnId, newColumnId, or column keys equal to '__proto__' or 'constructor'; load the patch after Grid or Dashboards is available.

  5. Compensating control

    Strip unsafe column IDs '__proto__' and 'constructor' from untrusted column data before passing it to the DataTable constructor, grid, or board.

Event History

Oct 28, 2026
Advisory Published
via GitHub·07:55 PM
Data Sourced
via GitHub·07:55 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

Who can exploit this issue?

An attacker must be able to control a column ID used when writing a single cell value to a data table. In Dashboard releases that support column aliases, control of an alias target can also be sufficient if it resolves to __proto__.

2

What is the practical impact of a successful write?

The attacker can add integer-keyed properties, corresponding to row indexes, to Object.prototype and set them to written values. Those inherited keys can affect out-of-range indexed reads on arrays and plain objects and appear during for...in iteration over unrelated objects.

3

Are all prototype properties writable through this issue?

No. The affected paths use a numeric row index as the property name, so an attacker can create integer-keyed properties but cannot reach arbitrary named properties through these paths.

4

Does using a literal __proto__ column ID always trigger the issue?

Not in Dashboards releases that still support column aliases: a literal __proto__ ID is resolved through the alias map and redirected harmlessly. However, an alias whose target is __proto__ reaches the vulnerable write path.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203