Search: h-w-g.com

### 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 input-type cell renderers copy every entry of the renderer's `attributes` option onto the input or select element they create, without checking the attribute names. An attacker who controls the Grid configuration can supply entries under a column's `cells.renderer.attributes` or `cells.editMode.renderer.attributes` whose names are event handlers, and those handlers execute in the origin of the page hosting the Grid. A view renderer places the handler on the input rendered in every row of the column as soon as the Grid renders; an edit-mode renderer places it on the input created when a cell enters edit mode, and that input is focused immediately, so a `focus` handler runs as soon as the user starts editing. Exploitation requires that untrusted data reach the Grid configuration and that a user hover over or focus one of the rendered inputs, or begin editing a cell. The Pro DataGrid that shipped inside the Dashboards package is included. ### Workarounds If your column configuration comes from a source you do not fully control, paste this snippet right after importing the `Grid` module: ```ts const ALLOWED_RENDERER_ATTRIBUTES = [ 'autofocus', 'checked', 'max', 'maxlength', 'min', 'minlength', 'multiple', 'pattern', 'placeholder', 'size', 'step' ]; const scrubColumn = (column) => { const cells = column?.cells; for (const renderer of [cells?.renderer, cells?.editMode?.renderer]) { const attributes = renderer?.attributes; if (attributes) { for (const key of Object.keys(attributes)) { if (!ALLOWED_RENDERER_ATTRIBUTES.includes(key.toLowerCase())) { delete attributes[key]; } } } } return column; }; const scrubOptions = (options) => { scrubColumn(options?.columnDefaults); (options?.columns || []).forEach(scrubColumn); return options; }; const proto = Grid.Grid.prototype; const loadUserOptions = proto.loadUserOptions; proto.loadUserOptions = function (options, ...rest) { scrubOptions(Grid.defaultOptions); return loadUserOptions.call(this, scrubOptions(options), ...rest); }; const updateColumn = proto.updateColumn; proto.updateColumn = function (columnId, options, ...rest) { return updateColumn.call(this, columnId, scrubColumn(options), ...rest); }; ``` ### 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/grid-lite@3.2.0`. If you load Highcharts Grid from a CDN, use a versioned URL, for example `https://cdn.jsdelivr.net/npm/@highcharts/grid-lite@3.2.0/grid-lite.js`. For more on each installation method, see the [installation guide](https://www.highcharts.com/docs/grid/installation).

### Impact A custom icon supplied under `rendering.icons` as an icon definition object is built by creating an SVG path for each of its child entries and setting every key of that entry as an attribute of the path, without filtering the attribute names; only the string form of the option is passed through the markup allow-list. An attacker who controls the Grid configuration can therefore supply child entries whose keys name event handlers, and those handlers execute in the origin of the page hosting the Grid. Custom icons take precedence over the built-in ones, so the attacker can replace icons that render without any further configuration, such as the sort icon shown in every column header by default and the pagination controls where pagination is enabled, and does not need any reference to a custom icon name. Exploitation requires that untrusted data reach the Grid configuration and that a user hover over or activate an affected icon. ### Workarounds If your Grid configuration comes from a source you do not fully control, paste this snippet right after importing the Grid module: ```ts (function () { const GridNS = typeof Grid !== 'undefined' ? Grid : undefined; const GridClass = GridNS && GridNS.Grid; if (!GridClass || !GridClass.prototype.loadUserOptions) { return; // Grid not loaded } const allowedPathAttributes = [ 'd', 'fill', 'opacity', 'stroke', 'stroke-width', 'stroke-linecap', 'stroke-linejoin', 'transform' ]; const originalLoadUserOptions = GridClass.prototype.loadUserOptions; function sanitizeIconValue(value) { if (!value || typeof value === 'string') { return value; } const children = value.children || []; const sanitizedChildren = []; for (let i = 0; i < children.length; i++) { const child = children[i] || {}; const clean = {}; for (let j = 0; j < allowedPathAttributes.length; j++) { const attr = allowedPathAttributes[j]; if (child[attr] !== undefined && child[attr] !== null) { clean[attr] = child[attr]; } } sanitizedChildren.push(clean); } return { width: value.width, height: value.height, viewBox: value.viewBox, fill: value.fill, children: sanitizedChildren }; } function sanitizeIconsMap(icons) { if (!icons) { return icons; } const out = {}; for (const key in icons) { if (Object.prototype.hasOwnProperty.call(icons, key)) { out[key] = sanitizeIconValue(icons[key]); } } return out; } GridClass.prototype.loadUserOptions = function (newOptions) { if ( newOptions && newOptions.rendering && newOptions.rendering.icons ) { newOptions.rendering.icons = sanitizeIconsMap( newOptions.rendering.icons ); } return originalLoadUserOptions.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/grid-lite@3.2.0`. If you load Highcharts Grid from a CDN, use a versioned URL, for example `https://cdn.jsdelivr.net/npm/@highcharts/grid-lite@3.2.0/grid-lite.js`. For more on each installation method, see the [installation guide](https://www.highcharts.com/docs/grid/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).

## Summary When `middleware.Static` is mounted globally (`e.Use(middleware.Static(...))`) and an application relies on a **route- or group-level middleware guard** to restrict a path that also falls under the served static root, a `%2F`-encoded request bypasses that guard while the file is still served. This is the same encoding/decoding mismatch fixed for `StaticFS`/`StaticDirectoryHandler` in CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq, but the fix did not cover the `middleware.Static` path. In addition, the `StaticConfig.EnablePathUnescaping` docstring states the default configuration prevents exactly this bypass, which is inaccurate for the global-mount case. **This is not path traversal:** no file outside the static root is accessed. The served file lives inside the static root; the issue is that access-control expectations set by a route guard are inconsistent between the literal and `%2F`-encoded forms of the same path. ## Details Root cause — the router and the static handler disagree on how to interpret `%2F`: - The router matches routes on the **raw, still-encoded** path, so `GET /admin%2Fsecret.txt` does **not** match a `/admin/...` route or group; any middleware attached to that route/group is therefore skipped. - `middleware.Static` selects its path source in `middleware/static.go` (~L219): with a global `e.Use` mount there is no wildcard route, so it uses `c.Request().URL.Path`, which `net/http` has already **decoded** (`%2F` → `/`). It then `path.Clean`s (~L235) and `Open`s (~L259) `admin/secret.txt`, serving the file. Net effect: for the literal path the guard runs; for the `%2F`-encoded path the guard is skipped but the same file is served. Relevant code: - `middleware/static.go` ~L219 (`p := c.Request().URL.Path`), ~L235 (`path.Clean`), ~L259 (`currentFS.Open`) - `StaticConfig.EnablePathUnescaping` docstring (`static.go` ~L60-67) — claims the default prevents the `/admin%2fprivate.txt` → `/admin/*` guard bypass; this is not true for the global mount. Relationship to prior advisories: - **CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq** (patched 5.2.0): same `%2F` router-vs-handler mismatch, but fixed for `StaticFS`/`StaticDirectoryHandler`. The `middleware.Static` path was not covered — this report is that gap. - **CVE-2026-25766 / GHSA-pgvm-wxw2-hrv9** (patched 5.0.3): a *different* issue (Windows backslash traversal **outside** the root). Referenced only to disambiguate; not the same as this report. ## PoC Environment: `golang:1.25`, module using the official release (`go get github.com/labstack/echo/v5@v5.3.1`, no local `replace`). Static root `public/` contains a marker file `public/admin/secret.txt` = `SECRET`. Minimal app (the pattern under test: static served globally + a group guard intended to protect `/admin`): ```go package main import ( "net/http" "github.com/labstack/echo/v5" "github.com/labstack/echo/v5/middleware" ) func main() { e := echo.New() e.Use(middleware.Static("public")) // serves ./public globally (default filesystem) admin := e.Group("/admin", func(next echo.HandlerFunc) echo.HandlerFunc { return func(c *echo.Context) error { return c.String(http.StatusUnauthorized, "auth required") } }) admin.GET("/secret.txt", func(c *echo.Context) error { return c.String(http.StatusOK, "handler") }) e.Start(":1323") } ``` Requests (unauthenticated): ``` # Literal: route matches -> group guard runs curl -i http://localhost:1323/admin/secret.txt # => 401 # %2F-encoded: route does NOT match -> guard skipped, but middleware.Static serves the file curl -i --path-as-is http://localhost:1323/admin%2Fsecret.txt # => 200, body: SECRET ``` Observed on `v5.3.1`: literal → `401`; `%2F` → `200` with the file contents. For contrast, serving via the (patched) `e.StaticFS("/")` returns `404` for the same `%2F` request, showing the `middleware.Static` path was not covered by the CVE-2026-55677 fix. ## Impact An unauthenticated remote user can retrieve a file served by `middleware.Static` even when the application attached a route/group middleware guard to that path, by substituting `/` with `%2F`. The consequence is limited to files already inside the served static root (CWE-863 authorization inconsistency; CWE-436 interpretation conflict) — **there is no access to files outside the static root**. **Honest caveat on validity / severity:** this only has security impact for applications that (a) serve a directory statically to the public *and* (b) place a sensitive file inside that same directory while relying on a *route-level* guard to protect it. That combination is arguably a misconfiguration — a statically-served directory is public by design — so maintainers may reasonably classify this as a documentation fix (correct the `EnablePathUnescaping` claim) or won't-fix rather than a code vulnerability. It is filed primarily because (1) the router-vs-handler `%2F` inconsistency is the exact class fixed in CVE-2026-55677 but left uncovered for `middleware.Static`, and (2) the doc

### Summary The `Context.JSONP`, `Context.JSONPBlob`, and internal `jsonPBlob` helper in `context.go` directly concatenate the caller-supplied `callback` parameter into a JavaScript response **without any validation, escaping, or allow-listing**. This creates a high-impact **reflected XSS** that can be triggered by any route passing attacker-controlled data (query string, form, header, path param, etc.) into the callback. **Present in current master and v5.1.0 (latest release).** ### Vulnerable Code (verbatim) ```go func (c *Context) jsonPBlob(code int, callback string, i any) (err error) { c.writeContentType(MIMEApplicationJavaScriptCharsetUTF8) c.response.WriteHeader(code) if _, err = c.response.Write([]byte(callback + "(")); err != nil { return } if err = c.echo.JSONSerializer.Serialize(c, i, ""); err != nil { return } if _, err = c.response.Write([]byte(");")); err != nil { return } return } func (c *Context) JSONP(code int, callback string, i any) (err error) { return c.jsonPBlob(code, callback, i) } func (c *Context) JSONPBlob(code int, callback string, b []byte) (err error) { c.writeContentType(MIMEApplicationJavaScriptCharsetUTF8) c.response.WriteHeader(code) if _, err = c.response.Write([]byte(callback + "(")); err != nil { return } if _, err = c.response.Write(b); err != nil { return } _, err = c.response.Write([]byte(");")) return } ``` No sanitization is performed on the callback string. ### Exploit (one-request repro) Any route using the official pattern is vulnerable: ``` Goe.GET("/api", func(c echo.Context) error { return c.JSONP(200, c.QueryParam("callback"), map[string]string{"status": "ok"}) }) ``` Attacker request: ``` GET /api?callback=alert(document.domain)%2f%2f HTTP/1.1 Host: target.com ``` Server response: ``` Content-Type: application/javascript; charset=utf-8 alert(document.domain)//({"status":"ok"}); ``` → Immediate arbitrary JavaScript execution (full reflected XSS). ### Impact - Session hijacking, cookie theft, account takeover, keylogging, defacement. - Works even with strict CSP (response is served as application/javascript). #### Affected Versions - All versions ≤ v5.1.0 (including current master) #### Workarounds Manually sanitize the callback before calling JSONP/JSONPBlob: ``` Gofunc safeCallback(cb string) string { if matched, _ := regexp.MatchString(`^[a-zA-Z0-9_.\[\]]+$`, cb); !matched { return "callback" } return cb } ``` Or migrate away from JSONP entirely (use CORS + application/json). ### References - https://github.com/labstack/echo/blob/master/context.go - https://echo.labstack.com/docs/cookbook/jsonp ## Patches Fixed in `github.com/labstack/echo/v5` v5.4.0 and `github.com/labstack/echo/v4` v4.16.0. `Context.JSONP` and `Context.JSONPBlob` accept only a callback that is empty, a JavaScript identifier or a dot-separated path of identifiers (ASCII letters, digits, `_` and `$`); any other callback returns a 400 Bad Request error wrapping `ErrInvalidJSONPCallback` and nothing is written. JSONP responses also carry `X-Content-Type-Options: nosniff`. ## Workarounds Validate the callback in your handler before calling `Context.JSONP`, for example against `^[A-Za-z_$][A-Za-z0-9_$]*(\.[A-Za-z_$][A-Za-z0-9_$]*)*$`, and set `X-Content-Type-Options: nosniff`. JSONP responses can be read by any website with the user's cookies, so do not serve data that requires authentication through JSONP.

## Summary When `echo.New()` is used without explicitly setting `Echo#IPExtractor`, the `RealIP()` method falls back to reading the client-supplied `X-Forwarded-For` (or `X-Real-IP`) header without any proxy-origin validation. The default `RateLimiter()` middleware derives its per-client identifier from `ctx.RealIP()`, so an attacker can rotate arbitrary values in the `X-Forwarded-For` header on each request to obtain a fresh rate-limit bucket and bypass IP-based throttling entirely. ## Affected Component - `context.go` — `(*Context).RealIP()` (lines 186–208), legacy fallback branch (lines 190–200) - `middleware/rate_limiter.go` — `DefaultRateLimiterConfig.IdentifierExtractor` (lines 46–58); `RateLimiter()` (lines 71–76) - `echo.go` — `New()` (lines 326–343), `IPExtractor` left `nil` by default ## Description ### `RealIP()` unconditionally trusts `X-Forwarded-For` when `IPExtractor` is unset `Context.RealIP()` (`context.go:186-208`) first checks `c.echo.IPExtractor`. When this field is `nil` (the default for `echo.New()`), it falls through to legacy behavior and returns the **first IP** from the `X-Forwarded-For` header — the position an attacker has full control over: ```go // context.go:186-200 func (c *Context) RealIP() string { if c.echo != nil && c.echo.IPExtractor != nil { return c.echo.IPExtractor(c.request) } // Fall back to legacy behavior if ip := c.request.Header.Get(HeaderXForwardedFor); ip != "" { i := strings.IndexAny(ip, ",") if i > 0 { xffip := strings.TrimSpace(ip[:i]) xffip = strings.TrimPrefix(xffip, "[") xffip = strings.TrimSuffix(xffip, "]") return xffip // ← attacker-controlled first IP } return ip } if ip := c.request.Header.Get(HeaderXRealIP); ip != "" { ... return ip // ← also attacker-controlled } ra, _, _ := net.SplitHostPort(c.request.RemoteAddr) return ra } ``` ### Rate limiter default identifier extractor calls `RealIP()` unconditionally `DefaultRateLimiterConfig` (`rate_limiter.go:46-58`) sets the identifier extractor to `ctx.RealIP()` with no guard for whether a safe `IPExtractor` is configured: ```go // rate_limiter.go:46-58 var DefaultRateLimiterConfig = RateLimiterConfig{ Skipper: DefaultSkipper, IdentifierExtractor: func(ctx *echo.Context) (string, error) { id := ctx.RealIP() // ← reads attacker-controlled header return id, nil }, ... } ``` `RateLimiter(store)` (`rate_limiter.go:71-76`) copies `DefaultRateLimiterConfig` directly: ```go // rate_limiter.go:71-76 func RateLimiter(store RateLimiterStore) echo.MiddlewareFunc { config := DefaultRateLimiterConfig config.Store = store return RateLimiterWithConfig(config) } ``` The result is that the most common usage pattern — `e.GET("/path", h, middleware.RateLimiter(store))` — produces a rate limiter whose per-client identifier is fully controlled by the requester. ### Framework acknowledges the issue for IP extraction but the rate limiter carries no warning `ip.go:27` explicitly states the default is insecure: > "Note: if you don't set `Echo#IPExtractor` explicitly, Echo fallback to legacy behavior, which is not a good choice." And `ip.go:117-119`: > "In default behavior, Echo sees all of first XFF header, X-Real-IP header and IP from network layer. As you might already notice, after reading this article, this is not good. Sole reason this is default is just backward compatibility." The `IPExtractor` mechanism (`ExtractIPDirect()`, `ExtractIPFromXFFHeader()`, `ExtractIPFromRealIPHeader()`) in `ip.go` exists precisely to close this gap. However, the `RateLimiter()` function and `DefaultRateLimiterConfig` have **no corresponding warning** and make no attempt to detect or flag that `IPExtractor` is unset, leaving operators who follow the standard rate limiter example silently exposed. The test `TestRateLimiterWithConfig_defaultConfig` (`rate_limiter_test.go:181-226`) itself drives the rate limiter by setting `X-Real-IP` directly on the test request — demonstrating that the identifier is freely injectable without comment or mitigation. ### Full execution chain 1. Server starts with `echo.New()` (no `IPExtractor` set) and `e.GET("/limited", h, middleware.RateLimiter(store))` 2. Attacker sends `GET /limited` with header `X-Forwarded-For: 1.2.3.4` — rate bucket for `1.2.3.4` consumed 3. Attacker sends `GET /limited` again with `X-Forwarded-For: 1.2.3.4` — second token consumed; if burst is 1, next request would be 429 4. Attacker sends `GET /limited` with `X-Forwarded-For: 5.6.7.8` — **new bucket created** for `5.6.7.8`, 200 OK returned 5. Attacker repeats step 4 with arbitrary IPs — rate limit never triggers; unlimited requests served ## Proof of Concept ```go package main import ( "net/http" echo "github.com/labstack/echo/v5" "github.com/labstack/echo/v5/middleware" ) func main() { e := echo.New()

## Summary The `MethodOverride` middleware accepts any non-empty string as the override target method — including safe methods (GET, HEAD, OPTIONS, TRACE) — when rewriting a POST request. When `MethodOverride` is registered before `CSRF` in the post-routing middleware chain (`e.Use()`), it rewrites the request method to a safe method before `CSRF` evaluates it. The CSRF middleware then skips token validation for the now-safe method, allowing state-changing POST handlers to execute without any CSRF check. Both the legacy token path and the modern `Sec-Fetch-Site` protection path are bypassed simultaneously. ## Affected Component - `middleware/method_override.go` — `MethodOverrideConfig.ToMiddleware()` (lines 55–71): no whitelist on the override target method - `middleware/csrf.go` — `CSRFConfig.ToMiddleware()` (lines 188–189): safe-method bypass branch reads the already-rewritten method - `middleware/csrf.go` — `checkSecFetchSiteRequest()` (line 283): `Sec-Fetch-Site` safe check also reads the rewritten method ## Description ### MethodOverride accepts safe methods as override targets `MethodOverrideConfig.ToMiddleware()` (`method_override.go:55-71`) restricts the **source** method (only POST requests are overrideable) but applies no whitelist to the **target**: ```go // method_override.go:61-67 req := c.Request() if req.Method == http.MethodPost { m := config.Getter(c) if m != "" { req.Method = m // ← any non-empty string accepted, including "GET" } } ``` The docstring's security claim — "For security reasons, only POST method can be overridden" — refers only to the source-method restriction. There is no guard preventing POST from being rewritten to `GET`, `HEAD`, `OPTIONS`, or `TRACE`. The test suite (`method_override_test.go`) only tests POST→DELETE and POST→PUT; POST→GET is never tested or blocked. ### CSRF safe-method branch reads the already-rewritten method `CSRFConfig.ToMiddleware()` (`csrf.go:188-189`) makes its validation decision based on `c.Request().Method` at the time it runs: ```go // csrf.go:188-189 switch c.Request().Method { case http.MethodGet, http.MethodHead, http.MethodOptions, http.MethodTrace: // skip validation — no token check default: // validate CSRF token ``` If MethodOverride has already run and set `req.Method = "GET"`, this `switch` falls into the skip branch regardless of the original HTTP method or what handler was matched. The `Sec-Fetch-Site`-based path in `checkSecFetchSiteRequest()` (`csrf.go:283`) is identically vulnerable: ```go // csrf.go:283 isSafe := slices.Contains(safeMethods, c.Request().Method) ``` With `req.Method = "GET"` (already rewritten), `isSafe = true` and the function returns `true` — the request is allowed even when `Sec-Fetch-Site` is `cross-site`. **Both** CSRF protection paths are bypassed in a single step. ### Execution chain In `echo.go:700`, routing and middleware wrapping are performed in one step: ```go h = applyMiddleware(e.router.Route(c), e.middleware...) ``` 1. `e.router.Route(c)` evaluates with `req.Method = "POST"` → matches and binds the POST `/transfer` handler 2. `applyMiddleware` wraps it: `MethodOverride → CSRF → postHandler` At request execution time: 3. **MethodOverride** runs: `req.Method == "POST"` → reads form field `_method` = `"GET"` → `req.Method = "GET"` → calls `next` 4. **CSRF** runs: `c.Request().Method` = `"GET"` → `case http.MethodGet` → **skips token validation** → calls `next` 5. **postHandler** runs (the handler matched in step 1 — the original POST `/transfer` state-change handler) The state-changing handler executes with no CSRF token validation and with no `Sec-Fetch-Site` check. ### The missing target-method whitelist is the root cause The legitimate use case for MethodOverride is allowing HTML forms (which only support GET/POST) to send PUT, DELETE, or PATCH requests. There is no legitimate scenario in which an HTML form needs to rewrite POST to GET — that can always be expressed as an ordinary GET request. Allowing POST→GET (and HEAD/OPTIONS/TRACE) serves no valid purpose and is inherently dangerous when any safe-method-aware security middleware (CSRF, logging, audit) appears downstream. ## Proof of Concept ```go package main import ( "net/http" echo "github.com/labstack/echo/v5" "github.com/labstack/echo/v5/middleware" ) func main() { e := echo.New() // MethodOverride before CSRF — both in e.Use() (post-routing) e.Use(middleware.MethodOverrideWithConfig(middleware.MethodOverrideConfig{ Getter: middleware.MethodFromForm("_method"), })) e.Use(middleware.CSRF()) e.POST("/transfer", func(c *echo.Context) error { return c.String(http.StatusOK, "transfer executed") }) e.Logger.Fatal(e.Start(":18080")) } ``` ```bash # Baseline — CSRF correctly blocks a POST without a valid token curl -i -X POST 'http://127.0.0.1:18080/transfer' \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data 'amount

## Summary The Echo proxy middleware (`middleware/proxy.go`) preserves an incoming `X-Real-IP` header verbatim and forwards it to the upstream service when `Echo#IPExtractor` is not configured — which is the default. Because any HTTP client can supply an arbitrary `X-Real-IP` value, an attacker can cause Echo to relay a spoofed client IP address to every upstream service behind the proxy, undermining upstream IP-based access controls, rate limiting, audit logging, and geo-restriction. ## Affected Component - `middleware/proxy.go` — `ProxyConfig.ToMiddleware()`, header-rewriting block (lines 351–355) ## Description ### The header-preservation condition passes spoofed values to upstream `ProxyConfig.ToMiddleware()` (`proxy.go:338-405`) prepares forwarding headers before dispatching each request. The `X-Real-IP` rewrite logic at lines 351-355 reads: ```go // proxy.go:351-355 // Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream. // However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor. if req.Header.Get(echo.HeaderXRealIP) == "" || c.Echo().IPExtractor != nil { req.Header.Set(echo.HeaderXRealIP, c.RealIP()) } ``` The condition is `TRUE` (and therefore overwrites the header with a derived value) only when: - The header is absent — `req.Header.Get(echo.HeaderXRealIP) == ""`; **or** - `IPExtractor` is explicitly configured — `c.Echo().IPExtractor != nil` The condition is `FALSE` — and the header is left **unchanged** — when the request arrives with an `X-Real-IP` header already set **and** `IPExtractor` is `nil`. Because `Echo.New()` leaves `IPExtractor` as `nil`, this is the out-of-the-box behaviour for every application that uses `Proxy()` or `ProxyWithConfig()` without extra configuration. An attacker who sets `X-Real-IP` to any value causes Echo to forward exactly that value to the upstream, with no modification or validation. ### The comment in the source code confirms intent and the security gap The inline comment at line 351-352 explicitly states: > "Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream. However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor." The framework is aware that the default is insecure and retains it for backward compatibility. No warning appears in the `Proxy()` or `ProxyWithConfig()` documentation, so operators who follow the standard setup example receive a silently insecure proxy configuration. This is structurally identical to the documented insecurity in `ip.go:27`: > "Note: if you don't set `Echo#IPExtractor` explicitly, Echo fallback to legacy behavior, which is not a good choice." ### Full execution chain 1. Attacker sends `GET /api/admin` to the Echo proxy with header `X-Real-IP: 203.0.113.1` (a trusted corporate IP) 2. `ToMiddleware()` evaluates the guard at line 353: header is present (`!= ""`), `IPExtractor` is `nil` → condition is `FALSE` 3. `req.Header.Set` is **not** called; the upstream request carries the original, attacker-supplied `X-Real-IP: 203.0.113.1` 4. Upstream service checks `X-Real-IP` against its IP allowlist → finds `203.0.113.1` → grants access 5. Attacker reaches an endpoint that should be restricted to the corporate IP range Secondary impact path (audit poisoning): - All upstream log entries, rate-limit counters, and geo-restriction checks are evaluated against `203.0.113.1` rather than the real client IP, rendering audit trails and security analytics unreliable. ## Proof of Concept ```go package main import ( "fmt" "log" "net/http" echo "github.com/labstack/echo/v5" "github.com/labstack/echo/v5/middleware" ) func main() { // Upstream server: echoes back the X-Real-IP it received upstream := http.NewServeMux() upstream.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "upstream sees X-Real-IP: %s\n", r.Header.Get("X-Real-IP")) }) go http.ListenAndServe(":9000", upstream) // Echo proxy — IPExtractor deliberately NOT set (the default) e := echo.New() targets := []*middleware.ProxyTarget{{URL: mustParse("http://127.0.0.1:9000")}} e.Use(middleware.Proxy(middleware.NewRoundRobinBalancer(targets))) log.Fatal(e.Start(":1323")) } ``` ```bash # Without spoofed header — upstream sees actual peer address curl http://127.0.0.1:1323/ # upstream sees X-Real-IP: 127.0.0.1 # With spoofed header — upstream sees attacker-supplied value curl -H 'X-Real-IP: 198.51.100.77' http://127.0.0.1:1323/ # upstream sees X-Real-IP: 198.51.100.77 ``` The attacker-supplied IP `198.51.100.77` arrives at the upstream unchanged. ## Impact - Upstream IP-based access controls (allowlists, blocklists, geo-restrictions) can be bypassed by supplying the expected IP in `X-Real-IP` - Upstream rate limiters that key on `X-Real-IP` are bypassable (same class as the Echo rate-limiter fi

## Summary The `/credentials/signurl` endpoint decides authorization from the client-supplied `X-Rucio-Account` HTTP header instead of the authenticated token's account. Any client holding **any** valid auth token (even a low-privilege account they legitimately own) can send `X-Rucio-Account: root` to pass the root-only permission check and have the Rucio server mint a presigned **read / write / delete** URL for an **arbitrary** object, signed with the RSE's stored S3 / GCS / Swift credentials. ## Details `SignURL.get()` takes the authorization principal from a request header and never uses the token-authenticated identity: ```python # lib/rucio/web/rest/flaskapi/v1/credentials.py account = request.headers.get('X-Rucio-Account', default=None) # L165 (attacker-controlled) ... result = get_signed_url(account, rse=rse, service=service, # L194 operation=operation, url=url, lifetime=lifetime, vo=vo) ``` The gateway then uses that header value as the `issuer` for the permission check: ```python # lib/rucio/gateway/credential.py auth_result = permission.has_permission(issuer=account, vo=vo, # L57 action='get_signed_url', kwargs=kwargs, ...) ``` and the permission function is root-only: ```python # lib/rucio/core/permission/generic.py def perm_get_signed_url(issuer, kwargs, session): return _is_root(issuer) # _is_root(x) -> x.external == 'root' ``` `InternalAccount('root', vo).external == 'root'` unconditionally, so the gate passes whenever the header is `root`. The endpoint is on `AuthenticatedBlueprint`, whose `before_request` hook validates the token and sets `request.environ['issuer']` **from the token** — but nothing ever compares `X-Rucio-Account` to it: ```python # lib/rucio/web/rest/flaskapi/v1/common.py (request_auth_env) flask.request.environ['issuer'] = auth.get('account') # L168 (the real account; unused by SignURL) ``` This is anomalous: every other authenticated handler derives the account from `request.environ['issuer']`; `credentials.py` is the only one that trusts the header. Additionally, `core.credential.get_signed_url` never checks that the supplied `url`'s host/bucket belongs to the target RSE, so even a legitimate `root` caller gets an arbitrary-object signing oracle. In multi-VO the VO is also read from the `X-Rucio-VO` header, allowing cross-tenant targeting. ## Proof of concept Request (any valid token + spoofed account): ``` GET /credentials/signurl?rse=<cloudRSE>&svc=s3&op=delete&url=https://victim-bucket.s3.amazonaws.com/important/dataset.root HTTP/1.1 X-Rucio-Auth-Token: <any valid token, even a low-privilege account> X-Rucio-Account: root Accept: application/octet-stream ``` Response: `200 OK` with a presigned DELETE URL the attacker replays directly against the storage backend. ## Impact A low-privilege Rucio user can read, overwrite, and delete arbitrary objects on any cloud-backed (S3/GCS/Swift) RSE using the server's stored credentials — enabling data exfiltration, tampering, and destruction, and cross-tenant access in multi-VO deployments. ## Credit Reported by seankohjs. Found via static analysis + manual verification.

## Summary With `SslMode` set to `VerifyCA` or `VerifyFull` with no configured CA certificate, an unvalidated TLS connection is treated as secure and a clear-text password can be sent before the certificate is checked. This can occur when relying on the password to validate a self-signed cert, e.g., MariaDB's [zero-configuration TLS](https://mariadb.com/docs/server/security/encryption/data-in-transit-encryption/zero-configuration-ssl). ## Impact An attacker who can deploy a man-in-the-middle MySQL proxy presenting any self-signed certificate can capture the plaintext database password of a client that: - uses `SslMode = VerifyCA` or `VerifyFull`, and - does not use the `SslCa` connection string option, and - uses a non-empty password. The attacker completes the TLS handshake with its own cert, requests a clear-text password authentication scheme (`mysql_clear_password`, or forces the `caching_sha2_password`/`sha256_password` clear-text fallback), and receives the password before the fingerprint check rejects the connection, defeating the man-in-the-middle protection `VerifyFull` is expected to provide. Not affected: a configured CA (`SslCa`), CA-validated TLS, local connections (Unix socket / loopback), or empty passwords. Using `SslMode` set to `Preferred` or `Required` is out of scope (this is documented as not authenticating the server). ## Workarounds Provide `SslCa` with `VerifyCA`/`VerifyFull`, use a local/Unix-socket connection, or avoid clear-text authentication. ## References - https://mariadb.org/mission-impossible-zero-configuration-ssl/

A stored cross-site scripting (XSS) vulnerability exists in the iCagenda extension for Joomla, specifically in the url-type event Custom Field. This affects versions 3.2.1 through 4.0.16 of the extension. The vulnerability allows an attacker with low privileges to inject malicious scripts that can be executed with high impact on confidentiality and integrity, requiring user interaction.

A CSV formula injection vulnerability exists in the iCagenda extension for Joomla versions 3.5.0 through 4.0.16. This flaw involves improper neutralization of formula elements in CSV files generated by the registrations export feature, which could allow malicious formulas to be injected into exported CSV data.