Search: 5.1.8.7

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

## 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 reflected cross-site scripting (XSS) vulnerability exists in the labstack echo Go web framework prior to versions 4.16.0 and 5.4.0. The vulnerability occurs in the Context.JSONP and Context.JSONPBlob methods, which concatenate an unvalidated callback parameter into a JavaScript response. This allows an attacker to inject executable script code if they can control the callback argument in an application route. The issue is fixed in versions 4.16.0 and 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.

CVE-2026-118262 is a resource management vulnerability in the labstack Echo Go web framework affecting versions 4.15.0 up to but not including 4.16.1, and 5.0.0 up to but not including 5.4.1. The issue occurs in Echo's Proxy middleware where resources such as handlers, goroutines, and network connections may be retained after a WebSocket client disconnects if the upstream connection remains open. This can lead to resource accumulation and potential denial of service. The vulnerability is fixed in versions 4.16.1 and 5.4.1.

n8n versions before 1.123.85, 2.43.5, and 2.44.1 contain an authorization bypass vulnerability. This flaw allows member users to access credentials they should not have permission to use by omitting default node parameters in workflows. Exploiting this, attackers can save and execute workflows that skip pre-execution credential checks, causing decrypted credential values to be sent to destinations controlled by the attacker.

CVE-2026-118675 is a credential guard bypass vulnerability in n8n versions before 1.123.85, 2.43.5, and 2.44.1. It allows editors of shared workflows to access restricted credentials by exploiting the Execute Sub-workflow node with maliciously crafted source URLs or local files. This vulnerability enables attackers to retrieve decrypted credential values improperly.

A vulnerability in n8n versions before 1.123.85, 2.x before 2.43.5, and 2.44.x before 2.44.1 causes the SeaTable Trigger node's API token to be saved in error execution data. This occurs because failed poll requests store raw request headers, exposing sensitive API tokens to users who can view workflow executions but do not have credential read access.

MIME::Words versions before 5.521 for Perl contain a vulnerability in the decode_mimewords function that allows memory exhaustion. This occurs when repeated "=?" sequences that do not form complete encoded words cause the function to append large error messages repeatedly, leading to significant memory consumption. From version 5.518, MIME::Parser decodes multipart boundaries using this function, enabling a remote sender to trigger this exhaustion via a crafted Content-Type header.

MIME::Field::ParamVal versions before 5.521 for Perl do not properly flag duplicate boundary parameters when the parameter name contains a nested comment. This causes the parser to store such parameters under their literal names instead of the expected 'boundary' name, allowing a second boundary parameter to go undetected as a duplicate. As a result, MIME::Parser splits the message on the second boundary, while readers that skip comments per RFC 5322 take the first boundary. This discrepancy allows a remote sender to hide an attachment from filters relying on ambiguous_content(), although the recipient's mail client will display the attachment.

MIME::Field::ParamVal versions before 5.521 for Perl contain a vulnerability that allows CPU exhaustion via unclosed comments in header parameters. The parsing logic scans from each opening parenthesis to the next closing parenthesis, but if a closing parenthesis is missing, the scan extends to the end of the header, causing quadratic time complexity in parsing. This can lead to significant CPU resource consumption, with a 40 KB header taking about 7 seconds to parse once.

MIME::Head versions from 5.518 up to but not including 5.521 for Perl improperly decode multipart boundaries that are partly RFC 2047 encoded without marking the parse as ambiguous. This allows a remote sender to craft a multipart boundary that bypasses filters relying on ambiguous_content() detection, potentially hiding attachments from such filters while still displaying them in the recipient's mail client.

MIME::Field::ParamVal versions before 5.521 for Perl do not properly flag ambiguous multipart boundaries when written as RFC 2231 continuations. This flaw allows a remote sender to craft a MIME message that causes MIME::Parser to split the message on a different boundary than other mail readers, potentially hiding attachments from filters relying on ambiguous_content() checks while the recipient's mail client displays them.

CVE-2026-118608 is an out-of-bounds read vulnerability in the prh_rfcomm_cc_process_test function of the libanwbtstack.so component on Alpine iLX-F511 devices. This flaw allows network-adjacent attackers who can pair a malicious Bluetooth device with the target to disclose sensitive information. The vulnerability arises from improper validation of user-supplied data, leading to reading beyond allocated buffer boundaries. It has a low CVSS score of 3.5 and does not impact integrity or availability.

An integer overflow vulnerability exists in the DPI certificate scanner of Juniper Networks Session Smart Router. This flaw allows an unauthenticated remote attacker to cause a denial of service by sending a specially crafted TLS server certificate. The vulnerability has a high severity rating with a CVSS score of 7.5. No affected versions or patch information are provided in the available data.

CVE-2026-103405 is an injection vulnerability in the web server component of Juniper Networks Session Smart Router and Session Smart Conductor. It allows an attacker to inject arbitrary HTTP headers by exploiting unsanitized request body parameters. The vulnerability has a medium severity with a CVSS score of 5.8. No affected versions or patch information are currently provided.