Search: 1.2.4.4

A race condition vulnerability in filelock versions 3.30.0 through 4.2.0 allows a local unprivileged user to swap a symbolic link at the <path>.filelock directory after an lstat check but before subsequent operations. This can cause the lock user's process to create claim files in an attacker-chosen directory, potentially disrupting other locks by causing stranded claims that lead to denial of service until manually force-broken. The vulnerability requires write access to the directory containing <path>.filelock and is mitigated by patch 4.2.1.

filelock versions 4.0.0 through 4.2.0 contain a vulnerability in SoftReadWriteLock where the holder record refresh writes through a hard link or hangs on a named pipe (FIFO) placed by another local user who owns the lock's .rw directory. This can cause the lock user's write_lock or read_lock operations to hang indefinitely and the heartbeat thread to stop without notification, allowing multiple processes to believe they hold the lock simultaneously. The issue requires local user access and specific conditions such as permissive hard-link policies or ownership of the lock directory. The vulnerability has medium severity with no confidentiality impact but can cause integrity loss and high availability impact. A fix is available in version 4.2.1.

OpenTelemetry Java's W3C trace-context propagator has a vulnerability that allows crafted tracestate headers to cause excessive CPU consumption due to quadratic regex backtracking. This can lead to denial of service by blocking the parsing thread. The issue affects versions prior to 1.67.0 and is fixed in version 1.67.0. Mitigation includes upgrading to 1.67.0 or later or rejecting oversized tracestate headers before extraction.

A vulnerability in the @graphql-tools/executor-legacy-ws package causes per-request WebSocket connection parameters to persist across different users. This stale authentication state leads to later users inheriting previous users' authentication credentials in the connection_init payload, potentially allowing unauthorized access to downstream GraphQL subscriptions. The issue affects versions prior to 1.1.36 and is fixed in version 1.1.36.

A path traversal vulnerability (CWE-22) exists in langchain-ai's langgraph Python SDK and langgraph versions prior to 0.4.6 and 1.2.14 respectively. The issue arises when certain helper functions interpolate user-controlled assistant_id and thread_id values into authenticated GET request paths without proper encoding, allowing relative path segments to access unintended server paths. This vulnerability is fixed in langgraph-sdk 0.4.6 and langgraph 1.2.14.

The decode-uri-component package prior to version 0.5.1 contains an uncontrolled resource consumption vulnerability. Its fallback decoding function can cause quadratic CPU usage when processing malformed inputs with many distinct percent-encoded sequences, leading to blocking of the Node.js event loop. This issue is resolved in version 0.5.1.

A vulnerability in honojs node-server versions from 1.19.10 up to but not including 2.1.3 allows an unauthenticated attacker to bypass middleware protections on static file serving. The issue arises because the serveStatic function decodes the request path a second time after initial decoding by Hono, leading to inconsistent path evaluation. This can cause the static file handler to serve files from within the configured static root directory that should be protected by middleware. The flaw does not allow directory traversal outside the static root. The vulnerability is fixed in version 2.1.3.

CVE-2026-118658 is an open redirect vulnerability in the labstack echo Go web framework. Versions prior to 4.15.2 and 5.1.1 allow an attacker to control the scheme used in redirects by manipulating certain forwarded scheme headers. This can lead to redirects using arbitrary URI schemes. The issue affects redirect middleware that uses Context.Scheme without validating the scheme. HTTPS-specific redirects are not affected. The vulnerability is fixed in versions 4.15.2 and 5.1.1.

CVE-2026-117574 is an authorization bypass vulnerability in Red Hat OpenShift AI's ai-gateway-payload-processing component. An authenticated attacker can specify another tenant's model identifier in requests, causing the service to inject that tenant's API keys without verifying authorization. This allows unauthorized use of another tenant's large language model resources and quotas. Exploitation requires valid user credentials, limiting unauthenticated remote attacks. The vulnerability is rated critical with a CVSS score of 9.1.

### Impact A dot-separated key path taken from `series.keys` is followed without filtering the individual segments. An attacker who controls `series.keys` and the matching point data can use a path such as `__proto__.polluted` to set arbitrary properties on `Object.prototype`. The resulting properties are visible to all JavaScript running in the page, not only to the chart. No user interaction is required beyond rendering the chart. The injected properties are inert until other code on the page reads them, so consequences depend on the consuming application. ### Workarounds Drop-in fix - for any versions affected (6.1.0-13.0.2). Add the below IIFE to run after Highcharts is loaded. ```javascript ((H)=>{const X = H.isObject;H.Point.prototype.setNestedProperty = function setNestedProperty(t,e,i){let s=i.split(".");return s.some(t=>"__proto__"===t||"constructor"===t)||s.reduce(function(t,i,s,o){let r=o.length-1===s;return t[i]=r?e:X(t[i],!0)?t[i]:{},t[i]},t),t};})(Highcharts); ``` [Live demo & testing](https://jsfiddle.net/BlackLabel/z3rbtm7u/) ### 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@13.1.1`. If you load Highcharts from the CDN, use the versioned URLs on code.highcharts.com, for example `https://code.highcharts.com/13.1.1/highcharts.js`. For more on each installation method, see the [installation guide](https://www.highcharts.com/docs/getting-started/installation).

### Impact When series columns are built from point objects, the point option keys are used directly as data column ids, so the write that populates a column reaches `Object.prototype` and the `Object` constructor. Keys named `__proto__` and `constructor` survive `JSON.parse` as own enumerable properties, so an attacker who controls the point objects can set integer-keyed properties on `Object.prototype`, one per point index, to values of their choosing. Named properties cannot be reached this way. The integer keys still affect every object in the page: reading an out-of-range index on any array or plain object returns the attacker's 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. The properties remain in place once the chart has been built, and no user interaction is required beyond rendering the chart. Consequences beyond disruption depend on the consuming application. ### Workarounds Drop-in fix - for any versions affected (6.1.0-13.0.2). Add the below IIFE to run after Highcharts is loaded. ```javascript ;!function(t){if(t&&t.Point&&!t.Point.prototype.protoPollutionPatched){var o=t.Point.prototype,r=o.optionsToObject,e=o.setNestedProperty,n=Object.prototype.hasOwnProperty;o.optionsToObject=function(t){if(t&&"object"==typeof t&&!Array.isArray(t)&&(n.call(t,"__proto__")||n.call(t,"constructor"))){var o={};for(var e in t)n.call(t,e)&&!c(e)&&(o[e]=t[e]);t=o}return r.call(this,t)},o.setNestedProperty=function(t,o,r){return String(r).split(".").some(c)?t:e.call(this,t,o,r)},o.protoPollutionPatched=!0}function c(t){return"__proto__"===t||"constructor"===t}}(Highcharts); ``` [Live demo & testing](https://jsfiddle.net/BlackLabel/nopc6vhj/) ### 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@13.1.0`. If you load Highcharts from the CDN, use the versioned URLs on code.highcharts.com, for example `https://code.highcharts.com/13.1.0/highcharts.js`. For more on each installation method, see the [installation guide](https://www.highcharts.com/docs/getting-started/installation).

### Impact The breadcrumbs `style` option is applied to the breadcrumb button as SVG attributes rather than as CSS, and the attribute names are not filtered. An attacker who controls the chart configuration can supply keys under `breadcrumbs.style` that name event handlers, and those keys become live handlers on the breadcrumb button, so the attacker's script runs in the origin of the page hosting the chart. The option is reached through `drilldown.breadcrumbs`, `navigation.breadcrumbs` and the `breadcrumbs` option of the treemap, sunburst and treegraph series. Exploitation requires that untrusted data reach the chart configuration and that a user drill down, or traverse into a level of a hierarchical series, so that the breadcrumbs render, and then hover over or activate the breadcrumb button. Charts rendered in styled mode do not apply the option and are not affected. Charts built with Highcharts Stock, Maps and Gantt are included, since those ship from the same package as Core. ### Workarounds Verified against published bundles on 10.0.0, 11.4.8, 12.3.0 and 13.0.2. Load immediately after Highcharts, before any chart is created: ```js // Workaround fix for all affected Highcharts versions: 10.0.0-13.0.2 ((H)=>{const S=H.SVGElement.prototype,D=S._defaultSetter;S._defaultSetter=function _defaultSetter(v,k,e){/^on/i.test(k)||D.call(this,v,k,e)};})(Highcharts); // End of the workaround fix ``` ### 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@13.1.0`. If you load Highcharts from the CDN, use the versioned URLs on code.highcharts.com, for example `https://code.highcharts.com/13.1.0/highcharts.js`. For more on each installation method, see the [installation guide](https://www.highcharts.com/docs/getting-started/installation).

### Impact The Highcharts component uses the value of `chartConstructor` to select a function from the Highcharts namespace and invokes it with the component's container element and its `chartOptions`, without checking the value against the supported chart constructors. An attacker who controls the dashboard configuration can therefore name any other public member of that namespace; utility functions in that namespace copy the supplied options onto the container element as properties or attributes, so markup and event handlers carried in `chartOptions` land in the page and run in the origin of the page hosting the dashboard. Exploitation requires that untrusted data reach the Dashboards component configuration. No user interaction is required beyond rendering the board. ### Workarounds If your board configuration comes from a source you do not fully control, paste this snippet right after importing libraries: ```ts (function () { const HighchartsComponent = Dashboards && Dashboards.HighchartsComponent; if (!HighchartsComponent || !HighchartsComponent.prototype.createChart) { return; // HighchartsComponent not loaded } const allowedConstructors = [ 'chart', 'stockChart', 'mapChart', 'ganttChart' ]; const originalCreateChart = HighchartsComponent.prototype.createChart; HighchartsComponent.prototype.createChart = function () { if (allowedConstructors.indexOf(this.chartConstructor) === -1) { this.chartConstructor = 'chart'; } return originalCreateChart.apply(this, arguments); }; }()); ``` ### 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](https://www.highcharts.com/docs/dashboards/installation).

### 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](https://www.highcharts.com/docs/dashboards/installation).

### Impact The data cursor keeps its listener and state bookkeeping in plain objects keyed by data table id, so a table id of `__proto__` supplied in the `dataPool` connector configuration resolves to `Object.prototype` when a sync registers its listeners, and the registration creates a property on `Object.prototype` named after the sync state and holding the internal listener array. The property name begins with a state prefix fixed by the library, to which the sync `group` option can append an attacker-chosen suffix, and its value is the library's own listener array, but the property is enumerable and visible on every object in the page, and emitting a lasting state for that table id then throws, so syncs that keep lasting states, such as `extremes`, stop working. Exploitation requires that untrusted data reach the Dashboards configuration and that a sync such as `highlight` or `extremes` be enabled on a component using that table, which the same configuration can do. No user interaction is required beyond loading the board. The injected property is inert until other code on the page reads or enumerates it, so consequences depend on the consuming application. ### Workarounds **Drop-in fix - for any Highcharts Dashboards versions affected (1.0.0-4.2.1).** Add the below IIFE to run after Highcharts Dashboards is loaded. ``` !function(t){if(t&&t.DataCursor&&t.DataTable){var e=t.DataCursor.prototype,r=t.DataTable.prototype;e.tableIdPollutionPatched||(e.tableIdPollutionPatched=!0,null!==Object.getPrototypeOf((new t.DataCursor).listenerMap)&&['addListener','emitCursor','remitCursor','removeListener'].forEach(function(t){var r=e[t];r&&(e[t]=function(){var t;return t=this,['listenerMap','stateMap'].forEach(function(e){var r,a=t[e];a&&null!==Object.getPrototypeOf(a)&&(r=Object.create(null),Object.keys(a).forEach(function(t){r[t]=a[t]}),t[e]=r)}),r.apply(this,arguments)})}),'__proto__'!==new t.DataTable({id:'__proto__'}).id||Object.getOwnPropertyDescriptor(r,'id')||Object.defineProperty(r,'id',{configurable:!0,enumerable:!0,get:function(){return this.safeTableId},set:function(e){'__proto__'!==e&&'constructor'!==e||(e=t.uniqueKey(),this.autoId=!0),this.safeTableId=e}}))}}(Dashboards); ``` [Live demo & testing](https://jsfiddle.net/BlackLabel/jwqazb51/) ### 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](https://www.highcharts.com/docs/dashboards/installation).

### Impact When the HTML text parser cannot obtain a document from `DOMParser` because the call throws, it falls back to assigning the raw markup to the `innerHTML` of an element created in the hosting document, and the allow-list is applied only to the resulting DOM afterwards. In Chromium the Trusted Types policy callback that the parser uses throws while a `beforeprint` handler is running, so if the hosting page re-renders the chart from a `beforeprint` handler, every HTML-rendered text option parsed at that moment, such as `useHTML` titles, axis labels and data labels or text set by responsive rules, is inserted unsanitized, and event handlers embedded in that markup run in the origin of the page hosting the chart. Exploitation requires that untrusted data reach the chart configuration, that the hosting page update the chart from a `beforeprint` handler in Chromium, and that printing be started, which the print item of the exporting menu does on its own. Charts built with Highcharts Stock, Maps and Gantt are included, since those ship from the same package as Core. ### Workarounds **Drop-in fix - for any versions affected (12.0.0-13.0.2).** Add the below IIFE to run after Highcharts is loaded. ``` ((n)=>{n.AST.prototype.parseMarkup=function parseMarkup(t){let e,i=[];t=t.trim().replace(/ style=(["'])/g," data-style=$1");try{e=new DOMParser().parseFromString(tI?tI.createHTML(t):t,"text/html")}catch{}if(!e)try{e=new DOMParser().parseFromString(t,"text/html")}catch{}e||((e=n.doc.implementation.createHTMLDocument("")).body.innerHTML=t);let s=(t,e)=>{let i=t.localName||t.nodeName.toLowerCase(),o={tagName:i};"#text"===i&&(o.textContent=t.textContent||"");let r=t.attributes;if(r){let t={};[].forEach.call(r,e=>{"data-style"===e.name?o.style=tB.parseStyle(e.value):t[e.name]=e.value}),o.attributes=t}if(t.childNodes.length){let e=[];[].forEach.call(t.childNodes,t=>{s(t,e)}),e.length&&(o.children=e)}e.push(o)};return[].forEach.call(e.body.childNodes,t=>s(t,i)),i};})(Highcharts); ``` [Live demo & testing](https://jsfiddle.net/BlackLabel/pb6jLf7g/) ### 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@13.1.0. If you load Highcharts from the CDN, use the versioned URLs on code.highcharts.com, for example https://code.highcharts.com/13.1.0/highcharts.js. For more on each installation method, see the [installation guide](https://www.highcharts.com/docs/getting-started/installation).

### Impact The filter applied to markup in text options checks `href`, `src` and a few similar attributes against an allowed-scheme list, but accepts `xlink:href` without that check, so an SVG anchor whose `xlink:href` is a `javascript:` URL passes the filter, whether or not the option is rendered with `useHTML`. In the live page the attribute is written without the XLink namespace, so browsers do not treat the anchor as a link there. The attribute is preserved verbatim in the chart's serialised output: the SVG produced by the exporting module, including the default SVG download, declares the XLink namespace and contains the anchor, and so does the markup of the chart container. Any document that parses that output again, such as the downloaded SVG opened in a browser or a page that inlines exported or server-rendered chart markup, then holds a working link, and an attacker who controls the chart configuration can thereby run script in the origin of that document when a user activates the link. Exploitation requires that untrusted data reach a text option such as the title, that the chart be exported or its markup be serialised and parsed again, and that a user activate the link. ### Workarounds Drop-in fix for all affected versions (10.3.2 - 13.1.0). Add the below IIFE to run after Highcharts is loaded, before creating a chart. ``` !function(t){var e=t&&t.AST;if(e&&"function"==typeof e.filterUserAttributes&&!e.xlinkHrefPatched){var r=e.filterUserAttributes,n=Object.prototype.hasOwnProperty;e.filterUserAttributes=function(t){return t&&n.call(t,"xlink:href")&&!o(t["xlink:href"])&&delete t["xlink:href"],r.call(this,t)},e.xlinkHrefPatched=!0}function o(t){var r=e.allowedReferences||["https://","http://","mailto:","/","../","./","#"];return"string"==typeof t&&r.some(function(e){return 0===t.indexOf(e)})}}(Highcharts); ``` ### 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@13.1.1`. If you load Highcharts from the CDN, use the versioned URLs on code.highcharts.com, for example `https://code.highcharts.com/13.1.1/highcharts.js`. For more on each installation method, see the [installation guide](https://www.highcharts.com/docs/getting-started/installation).