filelock versions 3.20.4 through 4.2.0 contain a vulnerability in the ReadWriteLock and AsyncReadWriteLock mechanisms where a crafted SQLite lock database file can cause every acquire operation to stall or hang indefinitely, ignoring timeout and blocking settings. This is due to the lock code running PRAGMA journal_mode=MEMORY on a fresh SQLite connection for each acquire, which loads the entire schema from the file at the lock path. A local attacker who can place or overwrite this file can cause denial of service by making acquires hang or spin at 100% CPU. The impact is availability only; no confidentiality or integrity is affected. The vulnerability is fixed in filelock 4.2.1.
A vulnerability in filelock versions 3.22.0 through 4.2.0 allows a local user with write access to a lock marker file to forge the process ID (PID) recorded in the marker. This causes another process, running as the lock owner or root, to mistakenly consider the lock stale and remove the live marker, resulting in two processes concurrently holding the lock. The issue arises when the marker file is group- or other-writable due to explicit mode settings or permissive umask values in sticky or non-removable directories. The vulnerability has a medium severity with a CVSS score of 4.7 and impacts integrity but not confidentiality or availability. A fix is available in version 4.2.1.
A symlink swap vulnerability in filelock's SoftFileLock writability check allows a local user with directory write access to leak one bit of information about whether a path exists and is writable by the lock user. This occurs due to a time-of-check to time-of-use (TOCTOU) race condition involving os.lstat and os.access calls. The vulnerability affects filelock versions 3.32.6 through 4.2.0 and is mitigated by Linux kernel's protected symlinks feature in common sticky world-writable directories like /tmp. The impact is limited to leaking a single bit of path existence and writability information with high attack complexity and no integrity or availability impact. A fix is available in version 4.2.1.
The filelock library's UnixFileLock backend on Unix systems truncates and changes permissions of any regular file that another local user renames or hard-links onto the lock path. This occurs when the lock user acquires the lock and the file exists at the lock path, leading to unintended truncation and potential permission escalation. The vulnerability affects all filelock versions up to and including 4.2.0 and requires local user access with certain directory permission conditions. The issue is fixed in version 4.2.1.
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).