Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-48714 | 9.1 critical | 1.0% | i18next, i18next-http-middleware | i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. In versions prior to 3.9.7, the missingKeyHandler blocked the literal request-body keys __proto__, constructor, and prototype (added in 3.9.3, see GHSA-5fgg-jcpf-8jjw), but did not reject dotted variants such as "__proto__.polluted". Downstream backends that split the missing-key string on a configured keySeparator (notably i18next-fs-backend ≤ 2.6.5) hand these keys to an unguarded setPath() walker that writes to Object.prototype. Applications that expose missingKeyHandler to untrusted input AND use i18next-fs-backend ≤ 2.6.5 are directly exploitable for remote prototype pollution. Other downstream backends that split the missing-key string the same way may be similarly affected. Depending on the host application, polluted prototype properties may cause crashes, corrupted translation behaviour, configuration poisoning, or bypasses of property-based security checks. This issue has been fixed in version 3.9.7. If developers cannot upgrade immediately, they should do the following: do not expose missingKeyHandler to untrusted users (mount it behind authentication, or remove the route), add a request-body filter ahead of the handler that rejects any top-level key containing __proto__, constructor, or prototype after splitting on their configured keySeparator, and disable missing-key persistence (saveMissing: false) when accepting writes from untrusted input. | Sun 25 Oct |
| CVE-2026-112362 | 9.1 critical | 0.00% | no CPE yet | @fastify/express is a Fastify plugin that runs Express middleware inside Fastify. In versions 4.0.5 through 4.0.8, when Fastify runs with the non-default ignoreDuplicateSlashes option enabled, the plugin matches path-scoped Express middleware against a URL whose duplicate-slash normalization has also collapsed the separator after an absolute-form request target's scheme, so Fastify's router resolves the request to the scoped path and runs the handler while the Express layer no longer sees that path. As a result, a request using an absolute-form target can reach a handler on a scoped route such as an admin path while the middleware for authentication, authorization, or rate limiting is skipped. An unauthenticated attacker needs only the non-default ignoreDuplicateSlashes option to be enabled. The issue is fixed in @fastify/express 4.0.9, and users should upgrade to 4.0.9 or later. As a workaround, enforce authentication in a Fastify hook such as preHandler that runs after the router resolves the request, or leave ignoreDuplicateSlashes at its default. | Tue 27 Oct |
| CVE-2026-33808 | 9.1 critical | 0.00% | fastify, fastify\/express | Impact@fastify/express v4.0.4 and earlier fails to normalize URLs before passing them to Express middleware when Fastify router normalization options are enabled. This allows complete bypass of path-scoped authentication middleware via duplicate slashes when ignoreDuplicateSlashes is enabled, or via semicolon delimiters when useSemicolonDelimiter is enabled. In both cases, Fastify router normalizes the URL and matches the route, but @fastify/express passes the original un-normalized URL to Express middleware, which fails to match and is skipped. An unauthenticated attacker can access protected routes by manipulating the URL path. PatchesUpgrade to @fastify/express v4.0.5 or later. | Mon 26 Oct |
| CVE-2026-33807 | 9.1 critical | 0.00% | fastify, fastify\/express | @fastify/express v4.0.4 and earlier contains a path handling bug in the onRegister function that causes middleware paths to be doubled when inherited by child plugins. When a child plugin is registered with a prefix that matches a middleware path, the middleware path is prefixed a second time, causing it to never match incoming requests. This results in complete bypass of Express middleware security controls, including authentication, authorization, and rate limiting, for all routes defined within affected child plugin scopes. No special configuration or request crafting is required. Upgrade to @fastify/express v4.0.5 or later. | Mon 26 Oct |
| CVE-2026-112712 | 9.1 critical | 0.00% | no CPE yet | @fastify/middie is the Express-style middleware engine for Fastify. In versions from 9.0.0 through 9.3.5, the use() function joined a path-scoped middleware's mount path to the plugin scope prefix in a way that could diverge from the path Fastify's router serves, most often when the scope prefix ended in a slash, and also for array mount paths and for mount paths written without a leading slash. When the two paths disagreed, the middleware was silently skipped while the route handler still ran, so path-scoped middleware such as authentication, authorization, or rate limiting could be bypassed by a single unauthenticated request. The issue is fixed in @fastify/middie 9.3.6, and users should upgrade to 9.3.6 or later. As a workaround, enforce authorization in a Fastify hook such as preHandler that runs after the router has resolved the request. | 22 Oct |
| CVE-2026-33805 | 9.0 critical | 0.00% | fastify, fastify\/http-proxy, reply-from | @fastify/reply-from v12.6.1 and earlier and @fastify/http-proxy v11.4.3 and earlier process the client's Connection header after the proxy has added its own headers via rewriteRequestHeaders. This allows attackers to retroactively strip proxy-added headers from upstream requests by listing them in the Connection header value. Any header added by the proxy for routing, access control, or security purposes can be selectively removed by a client. @fastify/http-proxy is also affected as it delegates to @fastify/reply-from. Upgrade to @fastify/reply-from v12.6.2 or @fastify/http-proxy v11.4.4 or later. | Mon 26 Oct |
| CVE-2026-54281 | 8.7 high | 0.00% | no CPE yet | Nest is a framework for building scalable Node.js server-side applications. Prior to 11.1.24, an authentication bypass vulnerability exists in @nestjs/platform-fastify. When middleware is registered through NestJS's MiddlewareConsumer.forRoutes() API on the Fastify adapter, an unauthenticated client can bypass the Nest middleware registered for that route by simply appending a trailing slash (/) to the request URL. This bypass works on the default Fastify adapter configuration. This vulnerability is fixed in 11.1.24. | Sun 25 Oct |
| CVE-2026-41683 | 8.6 high | 0.00% | no CPE yet | i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. Prior to version 3.9.3, i18next-http-middleware wrote user-controlled language values into the Content-Language response header after passing them through utils.escape(), which is an HTML-entity encoder that does not strip carriage return, line feed, or other control characters. When the application used an older i18next (< 19.5.0) that still exercised the backward-compatibility fallback at LanguageDetector.js:100 or otherwise produced a raw detected value, CRLF sequences in the attacker-controlled lng parameter reached res.setHeader('Content-Language', ...) verbatim. This issue has been patched in version 3.9.3. | Mon 26 Oct |
| CVE-2026-41690 | 8.6 high | 0.00% | no CPE yet | 18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. Versions prior to 3.9.3 allow an unauthenticated HTTP client to pollute Object.prototype in the Node.js process hosting the middleware, via two unvalidated entry points that reach internal object-key writes: getResourcesHandler and missingKeyHandler. This can break authorisation checks (if (user.isAdmin) returning true for any user), cause type-confusion DoS, and depending on downstream code it can be chained into RCE. | Mon 26 Oct |
| CVE-2026-42353 | 8.2 high | 0.00% | no CPE yet | i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. Prior to version 3.9.3, i18next-http-middleware passes the user-controlled lng and ns values from getResourcesHandler directly into i18next.services.backendConnector.load(languages, namespaces, …) without any sanitization. Depending on which backend is configured, the unvalidated path segments enable either path traversal or SSRF. This issue has been patched in version 3.9.3. | Mon 26 Oct |
| CVE-2026-42349 | 7.6 high | 0.00% | clerk, clerk\/astro, clerk\/backend, clerk\/chrome-extension | Clerk JavaScript is the official JavaScript repository for Clerk authentication. has(), auth.protect(), and related authorization predicates in @clerk/shared, @clerk/nextjs, @clerk/backend, and other framework SDKs can return true for certain combined authorization checks when the result should be false, allowing a gated action to proceed for a user who does not satisfy the full set of requested conditions. This call shape can be bypassed if certain conditions are met: a has() or auth.protect() call that combines a reverification check with any of role, permission, feature, or plan, or that combines a billing check (feature or plan) with a role or permission check. This vulnerability is fixed in @clerk/clerk-js 5.125.10 and 6.7.5. | Mon 26 Oct |
| CVE-2026-34076 | 7.4 high | 0.00% | no CPE yet | Clerk JavaScript is the official JavaScript repository for Clerk authentication. In @clerk/hono from versions 0.1.0 to before 0.1.5, @clerk/express from versions 2.0.0 to before 2.0.7, @clerk/backend from versions 3.0.0 to before 3.2.3, and @clerk/fastify from versions 3.1.0 to before 3.1.5, the clerkFrontendApiProxy function in @clerk/backend is vulnerable to Server-Side Request Forgery (SSRF). An unauthenticated attacker can craft a request path that causes the proxy to send the application's Clerk-Secret-Key to an attacker-controlled server. This issue has been patched in @clerk/hono version 0.1.5, @clerk/express version 2.0.7, @clerk/backend version 3.2.3, and @clerk/fastify version 3.1.5. | Mon 26 Oct |
| CVE-2026-107318 | 7.4 high | 0.00% | no CPE yet | @fastify/reply-from is a Fastify plugin that forwards requests to an upstream HTTP or HTTPS server. In versions prior to 12.7.0, all of the built-in HTTPS transports override the secure default and set rejectUnauthorized to false, so the proxy does not verify the TLS certificate of the upstream even when the application points it at an https upstream in the default configuration. An on-path network attacker can therefore impersonate the configured HTTPS upstream, read the credentials and request bodies the proxy forwards, and return forged responses that the application trusts. The issue is fixed in @fastify/reply-from 12.7.0, and users should upgrade to 12.7.0 or later. As a workaround, pass an explicit rejectUnauthorized true on the transport, supply an already configured undici instance, or use the undici global agent. | 9 Oct |
| CVE-2025-66415 | 6.9 medium | 0.00% | fastify, reply-from | fastify-reply-from is a Fastify plugin to forward the current HTTP request to another server. Prior to 12.5.0, by crafting a malicious URL, an attacker could access routes that are not allowed, even though the reply.from is defined for specific routes in @fastify/reply-from. This vulnerability is fixed in 12.5.0. | 18 Oct |
| CVE-2026-110024 | 6.8 medium | 0.00% | no CPE yet | @fastify/jwt is a JWT utility plugin for Fastify. In versions prior to 10.2.5, the top-level sign and verify methods replace the globally configured defaults with the per-call options instead of merging them, so passing any per-call option silently drops every global default that the call does not restate, including temporal protections such as token expiration and maximum accepted token age. A token signed this way carries no expiration claim and never expires, and verification stops enforcing a configured maximum age, so stale or never-expiring tokens are accepted. The route-level decorators for signing and verifying already merge options and are not affected. The issue is fixed in @fastify/jwt 10.2.5, and users should upgrade to 10.2.5 or later. | 20 Oct |
| CVE-2026-107275 | 6.8 medium | 0.00% | no CPE yet | @fastify/jwt is a JSON Web Token plugin for the Fastify web framework. In versions before 10.2.3, a time span passed to expiresIn, notBefore, or maxAge that the plugin's parser cannot read, such as a compound span, a month unit, an ISO 8601 duration, a decimal comma, or a value with surrounding whitespace, is silently dropped instead of refused. On the signing path this produces a token with no expiration claim that never expires, and on the verification path a configured maxAge stops being enforced, so a token that should be rejected for age is accepted. The issue is fixed in @fastify/jwt 10.2.3, and users should upgrade to 10.2.3 or later. As a workaround, pass these options as a number of seconds, or verify that any time-span string parses to a finite value before relying on it. | 8 Oct |
| CVE-2026-8723 | 6.3 medium | 0.00% | no CPE yet | ### Summary `qs.stringify` throws `TypeError` when called with `arrayFormat: 'comma'` and `encodeValuesOnly: true` on an array containing `null` or `undefined`. The throw is synchronous and not handled by any of qs's null-related options (`skipNulls`, `strictNullHandling`). ### Details In the comma + `encodeValuesOnly` branch, `lib/stringify.js:145` mapped the array through the raw encoder before joining: ```js obj = utils.maybeMap(obj, encoder); ``` `utils.encode` (`lib/utils.js:195`) reads `str.length` with no null guard, so a `null` or `undefined` element throws `TypeError`. `skipNulls` and `strictNullHandling` are both checked in the per-element loop below this line and never get a chance to run. Same class of bug as the filter-array path fixed in 0c180a4. The vulnerable shape of the comma + `encodeValuesOnly` branch was introduced in 4c4b23d ("encode comma values more consistently", PR #463, 2023-01-19), first released in v6.11.1. #### PoC ```js const qs = require('qs'); qs.stringify({ a: [null, 'b'] }, { arrayFormat: 'comma', encodeValuesOnly: true }); qs.stringify({ a: [undefined, 'b'] }, { arrayFormat: 'comma', encodeValuesOnly: true }); qs.stringify({ a: [null] }, { arrayFormat: 'comma', encodeValuesOnly: true }); // TypeError: Cannot read properties of null (reading 'length') // at encode (lib/utils.js:195:13) // at Object.maybeMap (lib/utils.js:322:37) // at stringify (lib/stringify.js:145:25) ``` #### Fix `lib/stringify.js:145`, applied in 21f80b3 on `main` and released as v6.15.2: ```diff - obj = utils.maybeMap(obj, encoder); + obj = utils.maybeMap(obj, function (v) { + return v == null ? v : encoder(v); + }); ``` `null` and `undefined` now pass through `maybeMap` unchanged and reach the `join(',')` step as-is. For `{ a: [null, 'b'] }` this produces `a=,b`, matching the non-`encodeValuesOnly` comma path (which already joins before encoding and produces `a=%2Cb` for the same input). Single-element `[null]` arrays still collapse via the existing `obj.join(',') || null` and remain subject to `skipNulls` / `strictNullHandling` in the main loop. ### Affected versions `>=6.11.1 <6.15.2` — fixed in v6.15.2. The vulnerable code shape was introduced in 4c4b23d and first shipped in v6.11.1. Earlier versions — including all of 6.7.x, 6.8.x, 6.9.x, 6.10.x, and 6.11.0 — implemented the comma + `encodeValuesOnly` path differently (joining before encoding) and are not affected. Empirically verified across released versions. ### Impact Application code that calls `qs.stringify` with both `arrayFormat: 'comma'` and `encodeValuesOnly: true` (both non-default) on input that may contain a `null` or `undefined` array element will throw synchronously instead of producing a query string. In a typical Node.js HTTP framework (Express, Fastify, Koa, hapi) the sync throw is caught by the framework's error boundary and the affected request returns a 500; the worker process does not exit and subsequent requests are unaffected. The "kills the worker process" framing applies only to call sites outside a request-handler error boundary (background jobs, startup paths, stream pipelines) or to deployments with framework error handling explicitly disabled. The vulnerable input is a `null` or `undefined` entry inside an array; this is reachable from JSON request bodies or from application code constructing arrays from user input, but not from standard HTML form submissions (which produce strings or omitted fields, not literal `null`). | 23 Oct |
| CVE-2026-74866 | 5.8 medium | 0.00% | fastify, fastify\/busyboy | @fastify/busboy is a multipart form-data parser for Node.js. Its multipart part-header parser splits header lines only on the two-byte carriage-return line-feed sequence, so a lone carriage return or line feed embedded in a part header is not treated as a line break and is carried verbatim into the parsed Content-Disposition filename and field name handed to the application. An attacker who uploads a file whose filename or field name contains a bare carriage return or line feed can inject control characters into consumers that trust the parser to return clean values, enabling filesystem filename pollution, log forging, or header injection when the value is forwarded to a carriage-return-sensitive sink. All versions of @fastify/busboy up to and including 3.2.1 are affected. The issue is fixed in version 3.2.2, which rejects any header line that still contains a bare carriage return or line feed. Users should upgrade to 3.2.2, and consumers such as @fastify/multipart should bump their @fastify/busboy dependency to pull in the fix. | 16 Oct |
| CVE-2026-110008 | 4.2 medium | 0.00% | no CPE yet | @fastify/oauth2 is a Fastify wrapper for OAuth2 login flows. In versions 7.2.0 through 8.3.1, the state and code-verifier cookies are set without a Path attribute at a login route with two or more path segments, while the clearing step at the OAuth callback writes them with a root path, so the original cookies survive the callback and the documented single-use guarantee for the state value does not hold. A state value an attacker learns stays valid for the rest of the browser session, letting the attacker drive their own authorization flow in the victim's browser and sign the victim in to the attacker's account (login CSRF). The issue is fixed in @fastify/oauth2 8.3.2, and users should upgrade to 8.3.2 or later. As a workaround, set an explicit cookie path so the set and the clear name the same cookie. | 19 Oct |
| CVE-2026-117499 | 3.7 low | 0.00% | no CPE yet | @fastify/session is a session plugin for Fastify. In all releases before 11.1.6, with the default rolling session behavior, a request that restored a session before a logout could save its own copy after another request had completed the session destroy call, recreating the destroyed session identifier with its authenticated data. An attacker who already holds a victim's valid signed session cookie and keeps a request in flight across the logout can replay that cookie to restore the session after it was meant to be revoked, without any cookie theft or signature forgery. The issue is fixed in @fastify/session 11.1.6, which adds a per session generation marker and a conditional store write so a session restored before a logout or regeneration cannot recreate or overwrite the current entry, and users should upgrade to 11.1.6 or later. There is no workaround, and custom session stores must implement the new conditional write. | Tue 27 Oct |
| CVE-2026-107832 | 3.7 low | 0.00% | no CPE yet | fastify is a fast and low overhead web framework for Node.js. In versions 5.12.2 through 5.12.5, the routine that lowercases header names declared in a route schema does not lowercase the enum or const header names nested inside a propertyNames subschema. As a result, a header allow-list or deny-list written with canonical (non-lowercase) casing never matches the incoming lowercased header, so a restricted header passes validation and reaches the route handler. An attacker can therefore bypass a case-sensitive header validation rule and smuggle a forbidden header past the schema, affecting the integrity of request handling. The issue is fixed in fastify 5.12.6, and users should upgrade to 5.12.6 or later. There is no workaround other than upgrading, though applications can declare header names in lowercase to avoid the mismatch. | 15 Oct |
21 of 21
Download these 21 as CSV · subscribe to this list.
EPSS scores: 2026-10-30. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.