The systeminformation library version prior to 5.33.13 contains a prototype pollution vulnerability in the networkStats() function. This occurs when the interface name '__proto__' is passed, causing writes to Object.prototype and polluting all objects in the Node.js process. The vulnerability affects applications running on FreeBSD, OpenBSD, or NetBSD that pass untrusted input to networkStats(). The impact includes unexpected properties appearing on all objects, which can alter application logic and enumeration behavior. No remote code execution or attacker-controlled values are known. A fix is available in version 5.33.13.
Vue I18n versions before 11.4.14 and certain 12.0.0-alpha versions have a vulnerability where the escapeParameter feature does not properly escape named interpolation values when a translation call passes both a list and named values. This can lead to unescaped HTML markup being inserted, potentially enabling DOM-based XSS if untrusted named values are rendered as HTML. The issue is fixed in versions 11.4.14 and 12.0.0-alpha.5.
Vue I18n versions prior to 11.4.14 and certain alpha versions of 12.0.0 contain a vulnerability where the escapeParameter feature does not properly sanitize the srcdoc attribute in iframe elements within translation messages. This allows an attacker to inject HTML content that the browser decodes and executes in the same origin, leading to DOM-based cross-site scripting (XSS). The issue arises because the sanitizer escapes characters using character references that are decoded inside srcdoc, bypassing the sanitization. The vulnerability is fixed in versions 11.4.14 and 12.0.0-alpha.5.
LangGraph Python SDK v3 streaming client versions 0.4.0 through 0.4.5 improperly handle unencoded thread_id and assistant_id values in request paths, allowing relative path segments to redirect authenticated GET requests to other paths on the same server. This affects also langgraph versions 1.2.3 through 1.2.13 when used with vulnerable SDK versions. The vulnerability allows an attacker controlling these identifiers to cause the SDK to fetch and return data from arbitrary readable paths on the server, but does not allow modification of data. The issue is fixed in langgraph-sdk 0.4.6 and langgraph 1.2.14.
Echo v5.2.0 and current master contain a vulnerability allowing bypass of route-level middleware protections for static files via encoded dot-dot traversal sequences. An attacker can access files intended to be protected by middleware by using encoded path segments such as %2E%2E, which are unescaped and normalized to access restricted directories. This bypass works with the default router configuration and a non-default configuration using UseEscapedPathForMatching=true. No patched version is currently known, but fixes are planned in versions 5.4.0 and 4.16.0.
Echo versions prior to 5.4.0 and 4.16.0 contain an open redirect vulnerability due to improper sanitization of redirect URIs. The sanitizeURI function only inspects the first two bytes of the URI for separator characters, allowing a control character such as a tab to prefix the URI and bypass the check. Browsers strip such control characters and normalize backslashes to forward slashes, causing the Location header to redirect to an attacker-controlled domain. This vulnerability has been confirmed with a proof of concept and affects the RemoveTrailingSlash middleware when configured to redirect.
The Echo web framework versions prior to 5.1.1 and 4.15.2 contain a vulnerability in the Scheme() method that trusts certain HTTP headers (X-Forwarded-Proto, X-Forwarded-Protocol, X-Url-Scheme) without validating their values. This allows attackers to inject arbitrary URI schemes into redirect URLs generated by the WWWRedirect and NonWWWRedirect middlewares, potentially leading to open redirect issues and cache poisoning. The vulnerability is fixed in Echo v5.1.1 and v4.15.2 by whitelisting accepted schemes.
Echo, a Go web framework, had a vulnerability in versions prior to 4.16.0 and 5.4.0 where it trusted forwarded scheme headers from any client. This allowed an attacker to bypass HTTPSRedirect by claiming an HTTPS scheme over plaintext HTTP, or suppress the Strict-Transport-Security header when behind a TLS-terminating proxy. The issue is fixed in versions 4.16.0 and 5.4.0.
A vulnerability in the labstack echo Go web framework allows double decoding of the same URL path data in middleware.Static prior to versions 4.15.3 and 5.2.0. This double decoding can reconstruct double-encoded separators before filesystem resolution, potentially allowing access to files under guarded routes when the static middleware is registered globally. The issue is fixed in versions 4.15.3 and 5.2.0.
### Impact
A `credits.href` value beginning with `javascript:` is assigned to the window location when the credits label is clicked, without being checked against an allowed-scheme list. An attacker who controls the chart configuration can therefore run script in the origin of the page hosting the chart. Exploitation requires that untrusted data reach the chart configuration and that a user click the credits label. 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 (5.0.0-13.0.2).
Add the below IIFE to run after Highcharts is loaded, but before a chart is created.
```js
!function(t){if(t&&t.Chart&&!t.Chart.prototype.creditsHrefPatched){var r=t.Chart.prototype,e=r.addCredits;r.addCredits=function(n){var o=t.merge(!0,this.options.credits,n);return o&&o.href&&!c(o.href)&&delete o.href,e.call(this,o)},r.creditsHrefPatched=!0}function c(r){var e=t.AST&&t.AST.allowedReferences||["https://","http://","mailto:","/","../","./","#"];return"string"==typeof r&&e.some(function(t){return 0===r.indexOf(t)})}}(Highcharts);
```
[Live demo & testing](https://jsfiddle.net/BlackLabel/6a09ws1f/)
### 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).
## 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
## 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
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.
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.
A vulnerability in the Echo Go web framework versions 4.0.0 up to but not including 5.4.0 allows an attacker to spoof the client IP address forwarded to upstream services via the X-Real-IP header when the Proxy middleware is used without configuring Echo.IPExtractor. This can undermine IP-based access controls, rate limiting, audit logging, or geographic restrictions. The issue is fixed in version 5.4.0.
CVE-2026-118650 is a vulnerability in the labstack Echo Go web framework affecting versions prior to 4.16.0 and 5.4.0. It involves improper handling of URL encoding in the globally mounted middleware.Static instance, where the static handler decodes the URL path differently than the router, leading to inconsistent route protection. This discrepancy can allow an encoded slash to resolve to files under the static root unexpectedly. The issue is fixed in versions 4.16.0 and 5.4.0.