🚨 [security] Update fastify 4.25.0 → 5.7.4 (major)

[depfu]

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ fastify (4.25.0 → 5.7.4) · Repo

Security Advisories 🚨

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

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

• fastify/lib/validation.js

  Line 272 in 759e978

      <tbody>
  

  return header.split(/[ ;]/, 1)[0].trim().toLowerCase()

• fastify/lib/content-type-parser.js

  Line 125 in 759e978

      <tbody>
  

  caseInsensitiveContentType.charCodeAt(parserListItem.length) === 9 /* `\t` */

• Fastify Validation and Serialization Documentation
• https://hackerone.com/reports/3464114

🚨 Fastify Vulnerable to DoS via Unbounded Memory Allocation in sendWebStream

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

• https://hackerone.com/reports/3524779

🚨 Fastify vulnerable to invalid content-type parsing, which could lead to validation bypass

Impact

In applications that specify different validation strategies for different content types, it's possible to bypass the validation by providing a slightly altered content type such as with different casing or altered whitespacing before ;.

Users using the the following pattern are affected:

fastify.post('/', {
  handler(request, reply) {
    reply.code(200).send(request.body)
  },
  schema: {
    body: {
      content: {
        'application/json': {
          schema: {
            type: 'object',
            properties: {
              'foo': {
                type: 'string',
              }
            },
            required: ['foo']
          }
        },
      }
    }
  }
})

User using the following pattern are not affected:

fastify.post('/', {
  handler(request, reply) {
    reply.code(200).send(request.body)
  },
  schema: {
    body: {
      type: 'object',
      properties: {
        'foo': {
          type: 'string',
        }
      },
      required: ['foo']
    }
  }
})

Patches

This was patched in v5.3.1, but unfortunately it did not cover all problems. This has been fully patched in v5.3.2.
Version v4.9.0 was also affected by this issue. This has been fully patched in v4.9.1.

Workarounds

Do not specify multiple content types in the schema.

References

Are there any links users can visit to find out more?

https://hackerone.com/reports/3087928

🚨 Fastify vulnerable to invalid content-type parsing, which could lead to validation bypass

Impact

In applications that specify different validation strategies for different content types, it's possible to bypass the validation by providing a slightly altered content type such as with different casing or altered whitespacing before ;.

Users using the the following pattern are affected:

fastify.post('/', {
  handler(request, reply) {
    reply.code(200).send(request.body)
  },
  schema: {
    body: {
      content: {
        'application/json': {
          schema: {
            type: 'object',
            properties: {
              'foo': {
                type: 'string',
              }
            },
            required: ['foo']
          }
        },
      }
    }
  }
})

User using the following pattern are not affected:

fastify.post('/', {
  handler(request, reply) {
    reply.code(200).send(request.body)
  },
  schema: {
    body: {
      type: 'object',
      properties: {
        'foo': {
          type: 'string',
        }
      },
      required: ['foo']
    }
  }
})

Patches

This was patched in v5.3.1, but unfortunately it did not cover all problems. This has been fully patched in v5.3.2.
Version v4.9.0 was also affected by this issue. This has been fully patched in v4.9.1.

Workarounds

Do not specify multiple content types in the schema.

References

Are there any links users can visit to find out more?

https://hackerone.com/reports/3087928

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)