Skip to content

chore(deps): update vulnerable [security] - #37

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/vulnerable
Open

renovate[bot] wants to merge 1 commit into
mainfrom
renovate/vulnerable

Conversation

@renovate

@renovate renovate Bot commented Jan 17, 2026 •

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
@grpc/grpc-js (source) 1.13.4 → 1.13.6 age confidence
fastify (source) 5.3.3 → 5.12.5 age confidence
tar 7.4.3 → 7.5.21 age confidence

@​grpc/grpc-js: An incoming malformed compressed message can cause a client or server crash

CVE-2026-48069 / GHSA-99f4-grh7-6pcq

More information

Details

Impact

An invalid incoming compressed message can cause a client or server process to crash. This affects all clients and servers that use @​grpc/grpc-js

Patches

The following version have fixes for this vulnerability:

  • 1.9.16
  • 1.10.12
  • 1.11.4
  • 1.12.7
  • 1.13.5
  • 1.14.4
Workarounds

There is no workaround.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


@​grpc/grpc-js: A malformed request can cause a server crash

CVE-2026-48068 / GHSA-5375-pq7m-f5r2

More information

Details

Impact

An invalid incoming HTTP/2 stream initiation can cause a server process to crash. This affects all servers created using @​grpc/grpc-js.

Patches

The following version have fixes for this vulnerability:

  • 1.9.16
  • 1.10.12
  • 1.11.4
  • 1.12.7
  • 1.13.5
  • 1.14.4
Workarounds

There is no workaround.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


@​grpc/grpc-js: The server transmits some error messages thrown by method handlers to the client in status messages

CVE-2026-101915 / GHSA-f596-whhp-79r4

More information

Details

Impact

If an application method handler crashes, the error message is included in the status message sent to the client. This can leak to the client any sensitive data that may be included in the error message. This impacts anyone using @grpc/grpc-js to run servers.

Patches

This vulnerability is fixed in 1.13.6 and 1.14.5.

Workarounds

This can be avoided by using a top-level error handler in method handlers to strip out sensitive error information.

Severity

  • CVSS Score: 3.7 / 10 (Low)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


@​grpc/grpc-js: In certain configurations, getAuthContext can return unauthorized certificates as though they were authorized

CVE-2026-101916 / GHSA-m9gg-hp2v-232j

More information

Details

Impact

When server credentials are created with the requireClientCertificate option set to false, getAuthContext does not distinguish between authorized and unauthorized certificates in its return value. This can create improper authentication vulnerabilities for @grpc/grpc-js users who use the result of getAuthContext for authentication.

In particular, @grpc/grpc-js-xds can both set the requireClientCertificate option to false and use the return value of getAuthContext for RBAC authentication in some configurations.

Patches

This vulenrability is fixed in 1.13.6 and 1.14.5.

Workarounds

@grpc/grpc-js users using getAuthContext this way can avoid this problem by setting requireClientCertificate to true. @grpc/grpc-js-xds users using RBAC can avoid this by setting the require_client_certificate field to true in the DownstreamTlsContext in the xDS configuration.

Severity

  • CVSS Score: 7.4 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


@​grpc/grpc-js: A malformed request can cause a server crash

CVE-2026-48068 / GHSA-5375-pq7m-f5r2

More information

Details

Impact

An invalid incoming HTTP/2 stream initiation can cause a server process to crash. This affects all servers created using @​grpc/grpc-js.

Patches

The following version have fixes for this vulnerability:

  • 1.9.16
  • 1.10.12
  • 1.11.4
  • 1.12.7
  • 1.13.5
  • 1.14.4
Workarounds

There is no workaround.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


@​grpc/grpc-js: An incoming malformed compressed message can cause a client or server crash

CVE-2026-48069 / GHSA-99f4-grh7-6pcq

More information

Details

Impact

An invalid incoming compressed message can cause a client or server process to crash. This affects all clients and servers that use @​grpc/grpc-js

Patches

The following version have fixes for this vulnerability:

  • 1.9.16
  • 1.10.12
  • 1.11.4
  • 1.12.7
  • 1.13.5
  • 1.14.4
Workarounds

There is no workaround.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


@​grpc/grpc-js: The server transmits some error messages thrown by method handlers to the client in status messages

CVE-2026-101915 / GHSA-f596-whhp-79r4

More information

Details

Impact

If an application method handler crashes, the error message is included in the status message sent to the client. This can leak to the client any sensitive data that may be included in the error message. This impacts anyone using @grpc/grpc-js to run servers.

Patches

This vulnerability is fixed in 1.13.6 and 1.14.5.

Workarounds

This can be avoided by using a top-level error handler in method handlers to strip out sensitive error information.

Severity

  • CVSS Score: 3.7 / 10 (Low)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


@​grpc/grpc-js: In certain configurations, getAuthContext can return unauthorized certificates as though they were authorized

CVE-2026-101916 / GHSA-m9gg-hp2v-232j

More information

Details

Impact

When server credentials are created with the requireClientCertificate option set to false, getAuthContext does not distinguish between authorized and unauthorized certificates in its return value. This can create improper authentication vulnerabilities for @grpc/grpc-js users who use the result of getAuthContext for authentication.

In particular, @grpc/grpc-js-xds can both set the requireClientCertificate option to false and use the return value of getAuthContext for RBAC authentication in some configurations.

Patches

This vulenrability is fixed in 1.13.6 and 1.14.5.

Workarounds

@grpc/grpc-js users using getAuthContext this way can avoid this problem by setting requireClientCertificate to true. @grpc/grpc-js-xds users using RBAC can avoid this by setting the require_client_certificate field to true in the DownstreamTlsContext in the xDS configuration.

Severity

  • CVSS Score: 7.4 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Fastify's Content-Type header tab character allows body validation bypass

CVE-2026-25223 / GHSA-jx2c-rxcm-jvmq

More information

Details

Impact

A validation bypass vulnerability exists in Fastify where request body validation schemas specified by Content-Type can be completely circumvented. By appending a tab character (\t) followed by arbitrary content to the Content-Type header, attackers can bypass body validation while the server still processes the body as the original content type.

For example, a request with Content-Type: application/json\ta will bypass JSON schema validation but still be parsed as JSON.

This vulnerability affects all Fastify users who rely on Content-Type-based body validation schemas to enforce data integrity or security constraints. The concrete impact depends on the handler implementation and the level of trust placed in the validated request body, but at the library level, this allows complete bypass of body validation for any handler using Content-Type-discriminated schemas.

This issue is a regression or missed edge case from the fix for a previously reported vulnerability.

Patches

This vulnerability has been patched in Fastify v5.7.2. All users should upgrade to this version or later immediately.

Workarounds

If upgrading is not immediately possible, user can implement a custom onRequest hook to reject requests containing tab characters in the Content-Type header:

fastify.addHook('onRequest', async (request, reply) => {
  const contentType = request.headers['content-type']
  if (contentType && contentType.includes('\t')) {
    reply.code(400).send({ error: 'Invalid Content-Type header' })
  }
})
Resources

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Fastify Vulnerable to DoS via Unbounded Memory Allocation in sendWebStream

CVE-2026-25224 / GHSA-mrq3-vjjr-p77c

More information

Details

Impact

A Denial of Service vulnerability in Fastify’s Web Streams response handling can allow a remote client to exhaust server memory. Applications that return a ReadableStream (or Response with a Web Stream body) via reply.send() are impacted. A slow or non-reading client can trigger unbounded buffering when backpressure is ignored, leading to process crashes or severe degradation.

Patches

The issue is fixed in Fastify 5.7.3. Users should upgrade to 5.7.3 or later.

Workarounds

Avoid sending Web Streams from Fastify responses (e.g., ReadableStream or Response bodies). Use Node.js streams (stream.Readable) or buffered payloads instead until the project can upgrade.

References

Severity

  • CVSS Score: 3.7 / 10 (Low)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


fastify: request.protocol and request.host Spoofable via X-Forwarded-Proto/Host from Untrusted Connections

CVE-2026-3635 / GHSA-444r-cwp2-x5xf

More information

Details

Summary

When trustProxy is configured with a restrictive trust function (e.g., a specific IP like trustProxy: '10.0.0.1', a subnet, a hop count, or a custom function), the request.protocol and request.host getters read X-Forwarded-Proto and X-Forwarded-Host headers from any connection — including connections from untrusted IPs. This allows an attacker connecting directly to Fastify (bypassing the proxy) to spoof both the protocol and host seen by the application.

Affected Versions

fastify <= 5.8.2

Impact

Applications using request.protocol or request.host for security decisions (HTTPS enforcement, secure cookie flags, CSRF origin checks, URL construction, host-based routing) are affected when trustProxy is configured with a restrictive trust function.

When trustProxy: true (trust everything), both host and protocol trust all forwarded headers — this is expected behavior. The vulnerability only manifests with restrictive trust configurations.

Severity

  • CVSS Score: 6.1 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Fastify has a Body Schema Validation Bypass via Leading Space in Content-Type Header

CVE-2026-33806 / GHSA-247c-9743-5963

More information

Details

Summary

A validation bypass vulnerability exists in Fastify v5.x where request body validation schemas specified via schema.body.content can be completely circumvented by prepending a single space character (\x20) to the Content-Type header. The body is still parsed correctly as JSON (or any other content type), but schema validation is entirely skipped.
This is a regression introduced by commit f3d2bcb (fix for CVE-2025-32442).

Details

The vulnerability is a parser-validator differential between two independent code paths that process the raw Content-Type header differently.
Parser path (lib/content-type.js, line ~67) applies trimStart() before processing:

const type = headerValue.slice(0, sepIdx).trimStart().toLowerCase()
// ' application/json' → trimStart() → 'application/json' → body is parsed ✓

Validator path (lib/validation.js, line 272) splits on /[ ;]/ before trimming:

function getEssenceMediaType(header) {
  if (!header) return ''
  return header.split(/[ ;]/, 1)[0].trim().toLowerCase()
}
// ' application/json'.split(/[ ;]/, 1) → ['']  (splits on the leading space!)
// ''.trim() → ''
// context[bodySchema][''] → undefined → NO validator found → validation skipped!

The ContentType class applies trimStart() before processing, so the parser correctly identifies application/json and parses the body. However, getEssenceMediaType splits on /[ ;]/ before trimming, so the leading space becomes a split point, producing an empty string. The validator looks up a schema for content-type "", finds nothing, and skips validation entirely.
Regression source: Commit f3d2bcb (April 18, 2025) changed the split delimiter from ';' to /[ ;]/ to fix CVE-2025-32442. The old code (header.split(';', 1)[0].trim()) was not vulnerable to this vector because .trim() would correctly handle the leading space. The new regex-based split introduced the regression.

PoC
const fastify = require('fastify')({ logger: false });

fastify.post('/transfer', {
  schema: {
    body: {
      content: {
        'application/json': {
          schema: {
            type: 'object',
            required: ['amount', 'recipient'],
            properties: {
              amount: { type: 'number', maximum: 1000 },
              recipient: { type: 'string', maxLength: 50 },
              admin: { type: 'boolean', enum: [false] }
            },
            additionalProperties: false
          }
        }
      }
    }
  }
}, async (request) => {
  return { processed: true, data: request.body };
});

(async () => {
  await fastify.ready();

  // BLOCKED — normal request with invalid payload
  const res1 = await fastify.inject({
    method: 'POST',
    url: '/transfer',
    headers: { 'content-type': 'application/json' },
    payload: JSON.stringify({ amount: 9999, recipient: 'EVIL', admin: true })
  });
  console.log('Normal:', res1.statusCode);
  // → 400 FST_ERR_VALIDATION

  // BYPASS — single leading space
  const res2 = await fastify.inject({
    method: 'POST',
    url: '/transfer',
    headers: { 'content-type': ' application/json' },
    payload: JSON.stringify({ amount: 9999, recipient: 'EVIL', admin: true })
  });
  console.log('Leading space:', res2.statusCode);
  // → 200 (validation bypassed!)
  console.log('Body:', res2.body);

  await fastify.close();
})();

Output:

Normal: 400
Leading space: 200
Body: {"processed":true,"data":{"amount":9999,"recipient":"EVIL","admin":true}}
Impact

Any Fastify application that relies on schema.body.content (per-content-type body validation) to enforce data integrity or security constraints is affected. An attacker can bypass all body validation by adding a single space before the Content-Type value. The attack requires no authentication and has zero complexity — it is a single-character modification to an HTTP header.
This vulnerability is distinct from all previously patched content-type bypasses:

CVE Vector Patched in 5.8.4?
CVE-2025-32442 Casing / semicolon whitespace ✅ Yes
CVE-2026-25223 Tab character (\t) ✅ Yes
CVE-2026-3419 Trailing garbage after subtype ✅ Yes
This finding Leading space (\x20) ❌ No

Recommended fix — add trimStart() before the split in getEssenceMediaType:

function getEssenceMediaType(header) {
  if (!header) return ''
  return header.trimStart().split(/[ ;]/, 1)[0].trim().toLowerCase()
}

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


fastify vulnerable to schema validation bypass via root primitive coercion mismatch

CVE-2026-18504 / GHSA-w2qp-rph6-63g4

More information

Details

Impact

fastify before 5.12.1, when a route uses a root-level primitive body schema (for example an integer with a minimum and maximum) and the default type coercion, validates the coerced value but exposes the original, uncoerced value to the route handler. For example, a JSON body "10" is coerced to the number 10 and passes an integer 1 to 10 schema, but request.body stays the string "10". An application that trusts the validated type is handed a value that did not satisfy the schema, which can bypass limits the application enforces on that typed value. Object and array body schemas are not affected, they coerce their members in place.

Patches

Upgrade to fastify 5.12.1.

Workarounds

Until you can upgrade, avoid relying on the validated type of a root primitive body. Wrap the value in an object schema (object properties are coerced in place), for example accept { "value": 10 } and read request.body.value, or re-check the type in the handler.

Severity

  • CVSS Score: 5.4 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


fastify vulnerable to authentication bypass via malformed URLs reaching encapsulated not-found handlers

CVE-2026-76169 / GHSA-p68q-wchp-6fh7

More information

Details

Impact

Fastify routes a malformed URL under one plugin prefix to the custom not-found handler of a different sibling plugin, invoking the handler registered last and skipping the preHandler declared in its setNotFoundHandler(). When the request method has no route in the main router, a malformed request target reaches Fastify's internal not-found router before URL decoding and is dispatched through a single shared handler pointer, regardless of prefix and without the normal request lifecycle. An unauthenticated request to a public prefix can therefore reach an authentication-protected not-found handler registered under a different prefix and receive its full response, breaking prefix encapsulation and bypassing the authentication hook. Applications whose private or tenant fallbacks return protected data from a not-found handler are affected.

Patches

Patched in fastify 5.12.2. Malformed URLs are now routed through the configured onBadUrl and onMaxParamLength handlers so they fail closed before any application not-found handler runs, and the shared not-found handler pointer has been removed.

Workarounds

Reject malformed request targets before they reach the application, for example at an upstream proxy or gateway, and do not rely on a not-found handler to serve protected data. A global onRequest authentication hook does not mitigate this, because the malformed-URL path skips it.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


fastify vulnerable to request body replacement via an async validation result collision

CVE-2026-84504 / GHSA-667r-xxjv-c9mm

More information

Details

Impact

Fastify runs a route's validator and, for a result shaped like { value, error }, unwraps it: an error becomes a validation failure and value replaces the request part. This convention is intended for synchronous custom compilers (for example Joi). A JSON Schema $async validator, however, resolves with the validated data itself, so Fastify applied the same unwrapping to it. If a request part validated by an $async schema contains a value property, Fastify replaced the whole request part with that nested value before the handler ran, so a value or error property in the payload was attacker-controlled. An application that dispatches operations from the validated request body could then act on data that never satisfied the route schema, leading to unauthorized state changes or disclosure. Reaching the vulnerable path requires the route to use an $async request schema.

Patches

Fastify no longer treats an asynchronous validation result as a { value, error } wrapper: an async validator's resolved value is used only to determine pass or fail, and it can no longer replace the request part or inject an error. The synchronous custom-compiler contract is unchanged. Patched in fastify 5.12.2 and 6.0.0.

Workarounds

If upgrading is not immediately possible, avoid $async request schemas, or perform the security-sensitive check in an onRequest or preHandler hook rather than relying on the schema-validated request part. Custom async validator compilers should signal failure by throwing (rejecting) rather than returning an { error } object.

Severity

  • CVSS Score: 8.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


fastify vulnerable to request validation bypass via skipped boolean false schemas

CVE-2026-84469 / GHSA-hwr6-493r-vm6h

More information

Details

Impact

Fastify decided whether to validate a request part by checking its schema for JavaScript truthiness. JSON Schema Draft 7 defines the boolean false as a valid schema that rejects every instance, but because false is falsy, a route that set body, querystring, params, or headers to false had that part left uncompiled: no validator was attached and the request reached the handler. An application that used false as a deny-all schema to make a route unreachable was therefore fully bypassed, and an unauthenticated remote client could reach the handler with any input. The same applied to the documented query alias for querystring. This is a complete bypass rather than a weak-schema issue, since false is the strongest JSON Schema assertion and must always fail.

Patches

Request-part schemas are now selected by an explicit presence check rather than truthiness, so a boolean false (or true) schema is compiled and enforced, including through the query alias. Patched in fastify 5.12.2. The fix is also included in the 6.0.0 release.

Workarounds

If upgrading is not immediately possible, express a deny-all request schema with an always-failing object schema instead of the boolean false (for example { "not": {} }), or reject the request in an onRequest hook.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


fastify vulnerable to header validation bypass via incomplete schema case normalization

CVE-2026-84428 / GHSA-9q9j-q6p8-xq58

More information

Details

Impact

Fastify lowercases header-schema property names before compiling the schema, because Node.js stores request header names in lowercase. That normalization was incomplete: it lowercased only top-level properties keys and the root required array, and did not lowercase the JSON Schema Draft 7 dependencies keyword (its trigger keys and dependent property names) or names in nested subschemas. As a result, a header schema that uses dependencies to require one header when another is present (for example X-Admin requiring X-Admin-Token) never matches the lowercased request headers, so the dependency assertion is silently skipped. An unauthenticated remote client can send the header that activates a privileged path while omitting the header the dependency was meant to require, bypassing a schema-enforced security control. The header schema is idiomatic, valid JSON Schema Draft 7, and no custom validator, malformed request, or misconfiguration is required.

Patches

Header-schema names are now normalized across all schema positions (properties, required, dependencies, dependentRequired, dependentSchemas, and nested subschemas). Patched in fastify 5.12.2. The fix is also included in the 6.0.0 release. Header schemas referenced through an external shared $ref (registered with addSchema) are not reached by this normalization and now emit an FSTSEC002 startup warning; inline the header schema to keep case-insensitive assertions in effect.

Workarounds

If upgrading is not immediately possible, write header-schema names in lowercase so the dependencies and other case-sensitive assertions match Node's lowercased request headers, or enforce the cross-header requirement in an onRequest or preValidation hook instead of the schema.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


fastify vulnerable to Denial of Service via unhandled exception on HTTP/2 trailer responses

CVE-2026-92081 / GHSA-4mh8-r7rc-xpvc

More information

Details

Impact

fastify crashes with an uncaught ERR_HTTP2_INVALID_CONNECTION_HEADERS exception when a route that registers a response trailer via reply.trailer() is served over HTTP/2. Fastify unconditionally adds the Transfer-Encoding: chunked header when a trailer is set, which is forbidden on HTTP/2, so Node.js throws while serializing the response headers. The exception is not caught and becomes an uncaughtException, terminating the Node.js process.

One unauthenticated HTTP/2 request to any route that uses trailers is enough to crash the server, dropping all in-flight requests, and the request can be repeated to keep the process down. Applications are affected only when HTTP/2 is enabled (http2: true) and at least one route registers a trailer. HTTP/1.x responses are not affected.

Patches

Upgrade to fastify 5.12.5 or later.

Workarounds

Avoid registering response trailers with reply.trailer() on routes served over HTTP/2 until upgrading.

Severity

  • CVSS Score: 5.9 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Fastify's Content-Type header tab character allows body validation bypass

CVE-2026-25223 / GHSA-jx2c-rxcm-jvmq

More information

Details

Impact

A validation bypass vulnerability exists in Fastify where request body validation schemas specified by Content-Type can be completely circumvented. By appending a tab character (\t) followed by arbitrary content to the Content-Type header, attackers can bypass body validation while the server still processes the body as the original content type.

For example, a request with Content-Type: application/json\ta will bypass JSON schema validation but still be parsed as JSON.

This vulnerability affects all Fastify users who rely on Content-Type-based body validation schemas to enforce data integrity or security constraints. The concrete impact depends on the handler implementation and the level of trust placed in the validated request body, but at the library level, this allows complete bypass of body validation for any handler using Content-Type-discriminated schemas.

This issue is a regression or missed edge case from the fix for a previously reported vulnerability.

Patches

This vulnerability has been patched in Fastify v5.7.2. All users should upgrade to this version or later immediately.

Workarounds

If upgrading is not immediately possible, user can implement a custom onRequest hook to reject requests containing tab characters in the Content-Type header:

fastify.addHook('onRequest', async (request, reply) => {
  const contentType = request.headers['content-type']
  if (contentType && contentType.includes('\t')) {
    reply.code(400).send({ error: 'Invalid Content-Type header' })
  }
})
Resources

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Fastify Vulnerable to DoS via Unbounded Memory Allocation in sendWebStream

CVE-2026-25224 / GHSA-mrq3-vjjr-p77c

More information

Details

Impact

A Denial of Service vulnerability in Fastify’s Web Streams response handling can allow a remote client to exhaust server memory. Applications that return a ReadableStream (or Response with a Web Stream body) via reply.send() are impacted. A slow or non-reading client can trigger unbounded buffering when backpressure is ignored, leading to process crashes or severe degradation.

Patches

The issue is fixed in Fastify 5.7.3. Users should upgrade to 5.7.3 or later.

Workarounds

Avoid sending Web Streams from Fastify responses (e.g., ReadableStream or Response bodies). Use Node.js streams (stream.Readable) or buffered payloads instead until the project can upgrade.

References

Severity

  • CVSS Score: 3.7 / 10 (Low)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


fastify: request.protocol and request.host Spoofable via

❗ Important

✂ PR body was truncated to here.

@renovate
renovate Bot requested a review from ferferga January 17, 2026 08:42
@renovate
renovate Bot force-pushed the renovate/vulnerable branch from 74ed197 to 8291022 Compare January 21, 2026 06:10
@renovate renovate Bot changed the title chore(deps): update dependency tar to v7.5.3 [security] chore(deps): update dependency tar to v7.5.4 [security] Jan 21, 2026
@renovate renovate Bot changed the title chore(deps): update dependency tar to v7.5.4 [security] chore(deps): update dependency tar to v7.5.7 [security] Feb 2, 2026
@renovate
renovate Bot force-pushed the renovate/vulnerable branch 2 times, most recently from 57c0622 to bbca5fe Compare February 2, 2026 23:05
@renovate renovate Bot changed the title chore(deps): update dependency tar to v7.5.7 [security] chore(deps): update vulnerable [security] Feb 2, 2026
@renovate
renovate Bot force-pushed the renovate/vulnerable branch 3 times, most recently from b7b9a39 to 0959fa9 Compare February 18, 2026 06:28
@renovate
renovate Bot force-pushed the renovate/vulnerable branch 2 times, most recently from b40ad96 to d7a35e7 Compare March 11, 2026 21:39
@renovate
renovate Bot force-pushed the renovate/vulnerable branch from d7a35e7 to 2d86b58 Compare March 25, 2026 21:45
@renovate
renovate Bot force-pushed the renovate/vulnerable branch from 2d86b58 to 501f089 Compare April 16, 2026 10:48
@renovate
renovate Bot force-pushed the renovate/vulnerable branch 2 times, most recently from 392faad to 7d76676 Compare May 18, 2026 16:02
@renovate
renovate Bot force-pushed the renovate/vulnerable branch 2 times, most recently from bfc3419 to d239d75 Compare June 15, 2026 23:37
@renovate
renovate Bot force-pushed the renovate/vulnerable branch 2 times, most recently from fb34bef to a1d635b Compare July 25, 2026 00:02
@renovate
renovate Bot force-pushed the renovate/vulnerable branch 2 times, most recently from a2e971d to 908543e Compare July 30, 2026 17:35
@renovate
renovate Bot force-pushed the renovate/vulnerable branch from 908543e to f82c022 Compare August 11, 2026 23:38
@renovate
renovate Bot force-pushed the renovate/vulnerable branch from f82c022 to b5834d7 Compare August 26, 2026 15:59
@renovate
renovate Bot force-pushed the renovate/vulnerable branch from b5834d7 to d0ff549 Compare September 3, 2026 01:38
@renovate
renovate Bot force-pushed the renovate/vulnerable branch from d0ff549 to dd059b0 Compare September 3, 2026 19:57
@renovate
renovate Bot force-pushed the renovate/vulnerable branch 3 times, most recently from ccba54f to f9b22b1 Compare September 17, 2026 16:58
@renovate
renovate Bot force-pushed the renovate/vulnerable branch 2 times, most recently from fe48d88 to a32c141 Compare September 20, 2026 17:26
@renovate
renovate Bot force-pushed the renovate/vulnerable branch from a32c141 to c268396 Compare October 1, 2026 06:03
@renovate
renovate Bot force-pushed the renovate/vulnerable branch from c268396 to c6bfb39 Compare October 5, 2026 13:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant