Mcollina

@fastify/aws-lambda version 6.4.0 decorates each Fastify request with request.awsLambda.event and request.awsLambda.context, values that applications are documented to use for authorization decisions such as reading API Gateway authorizer claims. In the default configuration, the getter that populates this decoration reads the client-controlled x-apigateway-event and x-apigateway-context HTTP headers before falling back to the trusted internal request token, and those reserved headers are not stripped from the incoming event. An unauthenticated attacker who can set a single HTTP header can therefore forge the entire Lambda proxy event, including the authorizer context, and override the genuine one. This results in a full authentication and authorization bypass and privilege escalation for any application that trusts request.awsLambda.event for identity or access control. Only version 6.4.0 is affected. Patches: upgrade to @fastify/aws-lambda 6.4.1, which resolves the decoration only through the internal per-invocation token and strips the reserved headers before the request is processed.

**Name of the Vulnerable Software and Affected Versions** fast-uri versions prior to 4.1.2 fast-uri versions prior to 3.1.5 fast-uri versions prior to 2.4.4 **Description** The software requires a literal double forward slash to recognize a URI authority. If a backslash-based introducer is used instead (such as backslash backslash, forward slash backslash, or backslash forward slash), the input is parsed without an authority and folded into the path. This creates a discrepancy with Node's native WHATWG URL parser, which treats backslashes as interchangeable with forward slashes for special schemes. Applications using the software to enforce host-based policies, such as allowlists, SSRF filtering, or redirect validation, before passing the URL to Node's URL or fetch consumers, may be steered to an unintended host. **Recommendations** Update to version 4.1.2. Update to version 3.1.5. Update to version 2.4.4.

**Name of the Vulnerable Software and Affected Versions** undici versions prior to 6.28.0 undici versions 7.0.0 through 7.28.x undici versions 8.0.0 through 8.8.x **Description** The retry interceptor can deliver a response where the body length does not match the `Content-Length` header after a retry or resume of a partial response. A malicious or faulty upstream server can return a partial response with a mismatched framing header and close the socket early, causing the retry interceptor to assemble a body of a different length while retaining the original `Content-Length`. This can lead to downstream response desynchronization, connection hangs, or response corruption in applications that forward upstream headers and bodies, such as proxies or gateways. Exploitation requires the retry interceptor to be enabled and a downstream forwarder that fails to remove or recalculate the `Content-Length` header. **Recommendations** Update to version 6.28.0 Update to version 7.29.0 Update to version 8.9.0

**Name of the Vulnerable Software and Affected Versions** @fastify/rate-limit versions prior to 11.2.0 **Description** Rate-limit buckets are keyed using the verbatim client IP string from `request.ip`. An IPv6-capable client can bypass rate-limit boundaries by rotating addresses within a large address range (such as a /64) or by using different textual representations of the same address. This allows attackers to bypass protections on sensitive endpoints like authentication, password reset, OTP delivery, or expensive API calls, particularly when the application is behind a proxy that surfaces IPv6 to the origin and `trustProxy` is enabled. **Recommendations** Update to version 11.2.0.

**Name of the Vulnerable Software and Affected Versions** undici versions 7.0.0 through 7.28.x undici versions 8.0.0 through 8.8.x **Description** The cache interceptor mishandles optional whitespace around the equals sign in qualified `no-cache` or `private` `Cache-Control` directives. The parser may drop the directive or store a field name containing literal quote characters, causing the cache decision to ignore the qualification and store the response. In shared-cache mode, this can lead to a response containing one user's authenticated data being served to a subsequent caller, including unauthenticated users, if both requests share the same cache key. This issue affects applications that enable the cache interceptor in shared mode, forward `Authorization` headers upstream, and receive cacheable responses with qualified directives containing whitespace around the equals sign. **Recommendations** Update to version 7.29.0. Update to version 8.9.0.

**Name of the Vulnerable Software and Affected Versions** undici versions 7.0.0 through 7.28.x undici versions 8.0.0 through 8.8.x **Description** The cache interceptor mishandles malformed `Cache-Control` private directives when used in shared mode. A degenerate qualified private directive, such as `private` set to an empty value, can cause a response to be stored in the default shared cache and subsequently served to different callers with the same cache key. This leads to the disclosure of private response bodies and headers, including `Set-Cookie`. Additionally, combining an unqualified private directive with a qualified one triggers an uncaught `TypeError` in the cache-control parser, which rejects the request and may terminate the process depending on the consumer's error handling. **Recommendations** Update undici versions 7.0.0 through 7.28.x to version 7.29.0. Update undici versions 8.0.0 through 8.8.x to version 8.9.0.

**Name of the Vulnerable Software and Affected Versions** @fastify/forwarded versions prior to 3.0.2 **Description** When the `X-Forwarded-For` header contains two or more comma-separated entries, the parser fails to strip horizontal tabs, trimming only space characters. This contradicts RFC 7230, which defines optional whitespace as both spaces and tabs. Consequently, an entry padded with a tab retains the literal tab character in the resolved address string. This can lead to the evasion of security mechanisms that rely on exact string matching of the resolved client IP, such as allowlists, blocklists, per IP rate limit keys, or audit log correlation, as the corrupted string will not match the expected value. **Recommendations** Update to version 3.0.2.

**Name of the Vulnerable Software and Affected Versions** undici versions prior to 6.28.0 undici versions 7.0.0 through 7.28.9 undici versions 8.0.0 through 8.8.9 **Description** The `setCookie()` function fails to fully sanitize cookie attributes. Specifically, the domain value is not checked for semicolons and entries in the unparsed array are not sanitized. This allows attacker-influenced input to inject additional cookie attributes. For instance, a domain value containing a semicolon can append attributes like `SameSite`, and an unparsed entry can inject attributes such as `HttpOnly` without the caller's intent. Applications passing user-controlled input to these fields, such as reverse-proxy or multi-tenant servers scoping session cookies to tenant-supplied domains, may experience bypassed SameSite CSRF protections or have the `Secure`, `HttpOnly`, and `SameSite` attributes forced, stripped, or overridden. **Recommendations** Update to version 6.28.0 Update to version 7.29.0 Update to version 8.9.0

undici does not validate the type property of a duck-typed blob-like request body before using it as the Content-Type header on the HTTP/1.1 dispatcher. In undici before 6.28.0, from 7.0.0 up to before 7.29.0, and from 8.0.0 up to before 8.9.0, an application that passes a hand-rolled blob-like body (via request, stream, pipeline, or dispatch) whose type is derived from untrusted input allows an attacker to inject CRLF sequences and append arbitrary HTTP headers, potentially smuggling a second request past the upstream. Native Blob objects are safe because their constructor strips CRLF from the type, and fetch is unaffected because it validates headers, but ecosystem libraries that build duck-typed blob shapes from user input can reach the vulnerable path. This is the same defect class as CVE-2022-35948 and CVE-2026-1527, on a header sink that the earlier fixes did not cover. The issue is fixed in undici 6.28.0, 7.29.0, and 8.9.0.

**Name of the Vulnerable Software and Affected Versions** @fastify/static versions prior to 10.1.1 **Description** An unauthenticated attacker can bypass route-scoped middleware and guards by using non-leading `..` and `%2E%2E` path segments in request pathnames. This occurs because the `find-my-way` router does not normalize dot-dot segments during route matching, causing requests to match the static plugin's catch-all instead of guarded routes. The `getPathnameForSend()` helper fails to reject these segments before the file-resolution stage, and the underlying `@fastify/send` library normalizes them before applying its own path-traversal guard. This allows the reading of files within the configured static root that are intended to be protected by URL prefix guards, although it does not allow access to files outside the static root. **Recommendations** Upgrade to @fastify/static version 10.1.1. As a temporary workaround, do not use route-based middlewares or guards to protect files served by @fastify/static.

**Name of the Vulnerable Software and Affected Versions** @fastify/static versions prior to 10.1.2 **Description** An unauthenticated attacker can bypass path-based filtering because the `allowedPath` callback is evaluated before the normalization of dot segments and duplicate path separators in the pathname used for file resolution. By requesting non-canonical pathnames, such as `//file`, `/./file`, or `/public/../private/file`, an attacker can access files that were intended to be denied. This issue defeats the security boundary established by `allowedPath` but does not allow access outside the configured static root. **Recommendations** Upgrade to @fastify/static version 10.1.2 or later.

**Name of the Vulnerable Software and Affected Versions** fast-uri versions 2.3.1 through 4.1.0 **Description** The software fails to treat a literal backslash character (U+005C) as an authority delimiter. Because Node's native WHATWG URL parser normalizes backslashes to forward slashes for specific schemes such as http, https, ws, wss, ftp, and file, the two parsers may extract different hosts from the same input string. This discrepancy can be exploited in applications that use fast-uri to enforce host-based policies—such as allowlists, denylists, loopback or SSRF (Server-Side Request Forgery) filtering, redirect validation, or outbound proxy routing—before passing the URL to Node's URL or fetch consumers. This can lead to requests being steered to unintended destinations, including internal hosts, loopback addresses, or cloud metadata endpoints. **Recommendations** Upgrade fast-uri versions 4.x to 4.1.1 Upgrade fast-uri versions 3.x to 3.1.4 Upgrade fast-uri versions 2.x to 2.4.3

**Name of the Vulnerable Software and Affected Versions** @fastify/http-proxy versions prior to 11.6.0 **Description** An improper input normalization issue exists where the software fails to rewrite the request prefix when the prefix segment is URL-encoded. While the router URL-decodes paths for route matching, the `request.url` retains the original encoded form, and the rewrite process uses a literal string replacement against the decoded prefix. This encoding mismatch allows a remote attacker to send requests with URL-encoded characters in the configured prefix, causing the proxy to match the route but skip the rewrite. Consequently, the raw encoded path is forwarded to the upstream server, which then decodes the path and serves it. This leads to a full proxy path bypass, exposing internal or administrative endpoints that were intended to be hidden via the `rewritePrefix` configuration, potentially resulting in unauthorized administrative actions and sensitive data exposure. **Recommendations** Upgrade to @fastify/http-proxy version 11.6.0.

**Name of the Vulnerable Software and Affected Versions** @fastify/reply-from versions 8.3.1 through 12.6.3 **Description** Internal URL cache keys are constructed by concatenating the destination and source paths without a delimiter. This allows different destination and source pairs to generate identical keys despite resolving to different upstream URLs. Consequently, when `getUpstream()` selects an upstream from request data, a cached URL for one upstream may be reused for a request intended for another, leading to cross-upstream data access and modification. Real-world incidents of elevated activity targeting this issue have been observed. **Recommendations** Upgrade to @fastify/reply-from version 12.6.4. As a temporary workaround, pass `disableCache: true` when registering the plugin.

**Name of the Vulnerable Software and Affected Versions** @fastify/http-proxy versions 9.4.0 through 11.5.0 **Description** WebSocket destination paths are not properly validated against the configured rewrite prefix. The `WebSocketProxy.findUpstream()` function resolves destinations using the WHATWG URL constructor, which collapses dot segments. This allows a crafted upgrade request containing path traversal sequences to bypass the rewrite prefix and access upstream endpoints that should not be exposed. This issue is exploitable via non-normalizing WebSocket clients, such as raw HTTP clients or downstream proxies that forward the request target without modification, as standard browsers and the `ws` package normalize paths before transmission. **Recommendations** Upgrade @fastify/http-proxy to version 11.6.0.

**Name of the Vulnerable Software and Affected Versions** @fastify/middie versions 9.1.0 through 9.3.2 **Description** An issue exists in the standalone engine's URL normalization and decoding process where malformed percent-encoded sequences in incoming request paths are not properly guarded. Specifically, inputs such as truncated multibyte sequences or incomplete percent escapes cause the underlying decoder to throw a synchronous exception. This exception escapes the normalization step and terminates the Node.js process, resulting in a denial of service for all connected clients. This affects applications that call the `middie.run()` function directly via the standalone engine API. Applications using the Fastify plugin path are not affected as the framework's error handler catches the exception. **Recommendations** Upgrade to @fastify/middie version 9.3.3. Migrate from the standalone engine API to the Fastify plugin path to allow the framework error handler to catch the exception.

**Name of the Vulnerable Software and Affected Versions** @fastify/middie versions 9.1.0 through 9.3.2 **Description** An authorization bypass occurs because the software decodes the encoded slash %2F within path parameter values before matching middleware paths, whereas the underlying router preserves this encoding during route lookup. This discrepancy allows a request to bypass middleware used for authentication, authorization, rate limiting, or auditing on parameterized paths, enabling an attacker to reach a protected handler using a crafted URL with an encoded slash in the parameter position. This issue is agnostic to the HTTP method and requires no authentication or special preconditions. **Recommendations** Upgrade to @fastify/middie version 9.3.3. Avoid using parameterized middleware paths for security decisions. Enforce authentication at the route handler or via a Fastify hook that executes after the router has resolved the request.

**Name of the Vulnerable Software and Affected Versions** undici versions 6.x prior to 6.26.0 undici versions 7.0.0 through 7.27.x undici versions 8.x prior to 8.5.0 **Description** The cookie parser in the `parseSetCookie` function percent-decodes cookie values using `qsUnescape`, which converts encoded sequences such as %0D%0A, %00, %3B, and %3D into literal byte equivalents. This behavior deviates from RFC 6265 §5.4 and browser standards, which do not specify such decoding. Applications that use `parseSetCookie`, `parseCookie`, or `getSetCookies` and subsequently forward these parsed values into response headers (such as proxies, middleware, or SSR frameworks) are susceptible to HTTP response header injection. This allows an attacker-controlled upstream source to inject arbitrary Set-Cookie, Location, or Cache-Control headers into the downstream response, potentially leading to session fixation, open redirect, or cache poisoning. **Recommendations** Upgrade to version 6.26.0 for versions in the 6.x branch. Upgrade to version 7.28.0 for versions in the 7.x branch. Upgrade to version 8.5.0 for versions in the 8.x branch. As a temporary workaround, sanitize values returned by `parseSetCookie()`, `parseCookie()`, or `getSetCookies()` to strip or reject CR, LF, NUL, ;, and = bytes before forwarding them into response headers.

**Name of the Vulnerable Software and Affected Versions** undici versions prior to 7.28.0 undici versions prior to 8.5.0 **Description** The cache interceptor incorrectly classifies certain responses as cacheable when the upstream Cache-Control header contains whitespace-padded qualified private or no-cache field names, such as `private=" authorization"` or `no-cache="tauthorization"`. Because the parser preserves this surrounding whitespace, comparisons against the literal `authorization` field name fail, causing the response to be stored. In shared-cache mode, this can lead to cross-user information disclosure, where a response containing one user's authenticated data is served from the cache to a subsequent caller, including unauthenticated users, if both requests share the same cache key. **Recommendations** Upgrade to version 7.28.0. Upgrade to version 8.5.0. Disable shared-cache mode for traffic that includes Authorization headers. Avoid caching responses to authenticated requests. Add `Vary: Authorization` upstream.

**Name of the Vulnerable Software and Affected Versions** undici version 8.1.0 **Description** The undici WebSocket client enforces `maxPayloadSize` on a per-frame basis but fails to enforce the cumulative size of fragmented uncompressed messages. A malicious WebSocket server can stream numerous small fragments that individually pass validation but collectively exceed the configured limit. This leads to unbounded memory growth in the client process, resulting in memory exhaustion and a denial of service. This issue affects applications using the `new WebSocket(...)` client that connect to compromised or attacker-controlled endpoints. **Recommendations** Upgrade to undici versions 8.5.0 or later.