Search: 1.2.4.4

### 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).

## 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 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

## URL sanitizer allows localhost/IPv6 loopback SSRF bypass via explicit port or bracketed IPv6 ### Summary `mcp-sanitizer` v1.3.3 fails to block Server-Side Request Forgery (SSRF) targets when a `localhost` URL includes an explicit port (e.g., `http://localhost:8080/`) or when an IPv6 loopback/link-local address is expressed in bracketed notation (e.g., `http://[::1]:8080/`, `http://[fe80::1]:8080/`). Because the library is explicitly designed to gate MCP tool parameters such as `web_fetch` and `web_scraper` before outbound HTTP requests are made, a bypass here directly enables an attacker-controlled URL to reach internal services, leaking their responses. ### Details The vulnerability exists in `src/utils/validation-utils.js` inside the `validateURLLocation()` function that is called by `_secureSanitizeURL()` in `src/sanitizer/mcp-sanitizer.js:698`. **Bug 1 — Port-guarded localhost check (line 274–276):** ```js // src/utils/validation-utils.js:274-276 if ((hostname === 'localhost' || hostname === '127.0.0.1' || hostname === '::1') && !parsedUrl.port) { throw new Error('URL points to localhost without explicit port'); } ``` The `&& !parsedUrl.port` guard means that any localhost URL that includes a port number is *not* thrown. `http://localhost:8080/` passes the check entirely, returning `blocked: false` with the original URL preserved. **Bug 2 — Bracketed IPv6 hostname mismatch (lines 272, 293–295):** ```js // src/utils/validation-utils.js:293-295 if (hostname.startsWith('169.254.') || hostname.startsWith('fe80:')) { throw new Error(`URL points to link-local address: ${hostname}`); } ``` The Node.js `URL` API returns `parsedUrl.hostname` for IPv6 addresses *with* surrounding brackets: `[::1]`, `[fe80::1]`. The string comparison `hostname === '::1'` (line 274) and `hostname.startsWith('fe80:')` (line 293) therefore never match, because the actual string starts with `[`. **Data flow through the middleware:** 1. `src/middleware/express.js:499` — tool name derived from `req.params.toolName || req.body?.tool_name`. 2. `src/middleware/express.js:548-554` — `web_scraper`/`web_fetch` `params.url` forwarded to `sanitizer.sanitize(url, { type: 'url' })`. 3. `src/sanitizer/mcp-sanitizer.js:527-528` — context type `url` routes to `_secureSanitizeURL()`. 4. `src/sanitizer/mcp-sanitizer.js:698-700` — `validateURLLocation(parsedUrl)` called; on success, `parsedUrl.toString()` returned to caller as the sanitized, trusted URL. Both bugs are in the default code path; no special configuration is required to trigger them. **Suggested patch:** ```diff --- a/src/utils/validation-utils.js +++ b/src/utils/validation-utils.js @@ const { URL } = require('url'); +const net = require('net'); @@ - const hostname = parsedUrl.hostname.toLowerCase(); + const hostname = parsedUrl.hostname.toLowerCase().replace(/^\[|\]$/g, '').replace(/\.$/, ''); @@ - if ((hostname === 'localhost' || hostname === '127.0.0.1' || hostname === '::1') && !parsedUrl.port) { - throw new Error('URL points to localhost without explicit port'); + if (hostname === 'localhost' || hostname.endsWith('.localhost') || hostname === '::1') { + throw new Error('URL points to localhost or loopback'); } @@ - if (hostname.startsWith('169.254.') || hostname.startsWith('fe80:')) { + if (hostname.startsWith('169.254.') || hostname.startsWith('fe80:') || + hostname.startsWith('fc') || hostname.startsWith('fd')) { throw new Error(`URL points to link-local address: ${hostname}`); } + + if (net.isIP(hostname) === 6 && (hostname === '::1' || hostname.startsWith('fe80:'))) { + throw new Error(`URL points to restricted IPv6 address: ${hostname}`); + } ``` ### PoC **Prerequisites:** Docker installed; no other dependencies required. **1. Build the Docker image:** ```bash docker build \ -f vuln-001/Dockerfile \ -t vuln-001-mcp-sanitizer \ reports/npmAI_754_starman69__mcp-sanitizer ``` **2. Run the PoC:** ```bash docker run --rm vuln-001-mcp-sanitizer ``` The `poc.py` script inside the image: - Starts a mock internal HTTP service on `127.0.0.1:8080` serving the string `INTERNAL_SECRET_DATA_9f3a2b1c`. - Calls `sanitizer.sanitize(url, { type: 'url' })` via Node.js for five URLs (two expected-blocked, three bypass candidates). - Performs an actual `GET http://localhost:8080/` using the sanitizer-approved URL and confirms the secret is returned. **Expected output (abbreviated):** ``` [BYPASS_CONFIRMED] http://localhost:8080/ blocked=False sanitized=http://localhost:8080/ [BYPASS_CONFIRMED] http://[::1]:8080/ blocked=False sanitized=http://[::1]:8080/ [BYPASS_CONFIRMED] http://[fe80::1]:8080/ blocked=False sanitized=http://[fe80::1]:8080/ [SSRF HTTP 200] GET http://localhost:8080/ => 'INTERNAL_SECRET_DATA_9f3a2b1c\npath=/' [!!!] INTERNAL SECRET EXFILTRATED: INTERNAL_SECRET_DATA_9f3a2b1c RESULT: PASS - SSRF bypass fully demonstrated end-to-end ``` Baseline controls confirm the library *does* block `http://localhost/`

## File Path Sanitizer Permits Arbitrary User-Home Absolute Paths ### Summary `mcp-sanitizer` v1.3.3 explicitly whitelists `/home/` and `/Users/` as allowed absolute path prefixes in its file path validation logic (`src/utils/validation-utils.js:188-196`). As a result, paths such as `/home/alice/.ssh/id_rsa` and `/home/alice/.aws/credentials` pass through `sanitizer.sanitize()` with `blocked=false`, even though they point to highly sensitive files outside any configured safe root. Any consumer application that trusts the sanitized path and passes it to a filesystem read/write operation (e.g., `fs.readFile`) will expose arbitrary user-home directory files to an unauthenticated network attacker. Dynamic reproduction confirmed exfiltration of a simulated SSH private key and AWS credentials via a single HTTP POST request. ### Details The vulnerability resides in the `validateFilePath` function inside `src/utils/validation-utils.js`. When an absolute path falls outside the configured safe root directories, the function performs a secondary check against a hardcoded allowlist: ```js // src/utils/validation-utils.js:188-196 if (!isInSafeLocation && path.isAbsolute(normalizedPath)) { const allowedAbsolutePaths = ['/tmp/', '/var/tmp/', '/home/', '/Users/']; const isAllowedAbsolute = allowedAbsolutePaths.some(allowed => normalizedPath.toLowerCase().startsWith(allowed.toLowerCase()) ); if (!isAllowedAbsolute) { throw new Error('Absolute path not in allowed safe directory'); } } ``` Because `/home/` and `/Users/` are included in `allowedAbsolutePaths`, any path beneath those directories — including `~/.ssh/id_rsa`, `~/.aws/credentials`, `~/.kube/config`, `~/.gnupg/`, etc. — is considered safe and passes validation unchanged. The dangerous paths (`dangerousUnixPaths` at `src/utils/validation-utils.js:135`) only cover `/etc/`, `/proc/`, `/sys/`, `/dev/`, `/root/`, `/boot/`, `/usr/bin/`, and `/sbin/`. Home-directory sensitive subdirectories (`.ssh`, `.aws`, `.gnupg`, `.kube`, `.config`) are never checked. The full data flow from a network request to the vulnerable return value is: 1. **`src/middleware/express.js:538-541`** — The Express middleware routes `file_reader`/`file_writer` tool parameters to `sanitizer.sanitize(params.file_path, { type: 'file_path' })`. 2. **`src/sanitizer/mcp-sanitizer.js:523-524`** — When `context.type === 'file_path'`, `_secureSanitizeFilePath()` is called. 3. **`src/sanitizer/mcp-sanitizer.js:683-687`** — `validateFilePath()` is invoked; if it does not throw, the normalized path is returned as the sanitized value. 4. **`src/utils/validation-utils.js:188-196`** — The `/home/` prefix check passes without error. 5. **`src/utils/validation-utils.js:200-201`** — The original, attacker-controlled absolute path is returned to the caller as a trusted, sanitized value. A consumer application receiving `{ blocked: false, sanitized: '/home/victim/.ssh/id_rsa' }` is expected to use that path for I/O. The sanitizer's own `README` and middleware integration imply that a `blocked: false` result is safe to act upon. **Suggested patch:** ```diff --- a/src/utils/validation-utils.js +++ b/src/utils/validation-utils.js @@ const dangerousUnixPaths = ['/etc/', '/proc/', '/sys/', '/dev/', '/root/', '/boot/', '/usr/bin/', '/sbin/']; + const sensitiveHomeFragments = [ + '/.ssh/', '/.aws/', '/.gnupg/', '/.kube/', '/.config/', + '/.npmrc', '/.env' + ]; @@ + const normalizedForSensitiveCheck = normalizedPath.replace(/\\/g, '/').toLowerCase(); + if (sensitiveHomeFragments.some(fragment => normalizedForSensitiveCheck.includes(fragment))) { + throw new Error('Access to sensitive user configuration path not allowed'); + } @@ - const allowedAbsolutePaths = ['/tmp/', '/var/tmp/', '/home/', '/Users/']; + const allowedAbsolutePaths = ['/tmp/', '/var/tmp/']; ``` ### PoC **Environment requirements:** Docker, Python 3, Node.js 20 **Step 1 — Build and start the reproduction container:** ```bash # From the vuln-002/ directory python3 poc.py ``` The script automatically: 1. Copies the `mcp-sanitizer` source into a Docker build context. 2. Creates simulated victim files at `/home/victim/.ssh/id_rsa` and `/home/victim/.aws/credentials` inside the container. 3. Builds a consumer HTTP server (`server.js`) that calls `sanitizer.sanitize()` and then `fs.readFile` on the returned path. 4. Sends the three test requests described below. **Step 2 — Manual HTTP requests (after the container is running on port 13572):** Control test — must be blocked: ```bash curl -s -X POST http://127.0.0.1:13572/tool \ -H 'Content-Type: application/json' \ -d '{"tool_name":"file_reader","parameters":{"file_path":"/etc/passwd"}}' # Expected: {"blocked": true} ``` Exploit test 1 — SSH private key exfiltration: ```bash curl -s -X POST http://127.0.0.1:13572/tool \ -H 'Content-Type: application/json' \ -d '{"tool_name":"file_reader","parameters":{"file_path":"/home/victim/.ssh/id_rsa"}}' # Expec

## 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.

Caddy v2 prior to 2.11.5 has a vulnerability where hop-by-hop headers defined in RFC 7230 §6.1 are not stripped from upstream responses during WebSocket protocol upgrades (HTTP 101 Switching Protocols). This allows headers such as Alt-Svc, Keep-Alive, Proxy-Authenticate, and Set-Cookie to leak through to clients, potentially enabling connection hijacking, cookie injection, and proxy authentication phishing. The issue arises because the code path handling 101 responses returns early and bypasses the header stripping logic that is correctly applied to normal HTTP responses.

CVE-2026-54162 affects Ember, a real-time terminal dashboard for Caddy servers. Versions prior to 1.4.2 improperly handle terminal escape and control sequences in HTTP request URIs within interactive TUI row formatters. This allows unauthenticated remote clients to inject control bytes that are interpreted by the terminal when viewing logs, leading to potential monitoring-dashboard spoofing, clipboard hijacking, and window-title spoofing. The issue is fixed in version 1.4.2.

A vulnerability in the Echo Go web framework versions 4.0.0 through 5.0.x allows remote attackers to bypass IP-based rate limiting. The issue arises because Context.RealIP falls back to client-supplied X-Forwarded-For or X-Real-IP headers when Echo.IPExtractor is unset, enabling attackers to rotate these headers to evade rate limits. This flaw is fixed in Echo version 5.1.0.

CVE-2026-115415 is a vulnerability in the environment tool of Strands Agents Tools where a crafted prompt can bypass secret masking. This allows an attacker to retrieve environment variables, including sensitive cloud credentials and API keys, in cleartext without operator consent. The issue affects versions from 0.1.0 up to but not including 0.8.6.

FearlessCMS versions prior to 0.1.4 contain multiple critical security flaws in five debug/test PHP scripts under the admin directory. These scripts lack authentication checks, CSRF protection, and proper path validation, allowing attackers to bypass admin login via crafted URIs. Vulnerabilities include arbitrary file writes enabling site defacement and stored cross-site scripting, arbitrary directory enumeration and file reads exposing sensitive metadata, and unauthenticated log file writes leading to potential disk exhaustion. The issue is fixed in version 0.1.4.