FileTypeValidator naive file type checking (@nestjs/common vulnerability)

[JuanRosero97]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

Snyk is reporting a vulnerability with @nestjs/common reported at this URL: Snyk Report

According to reports, there is no version that prevents this vulnerability. Is there any way you can help me?

Minimum reproduction code

https://codesandbox.io/p/sandbox/github/nestjs/typescript-starter

Steps to reproduce

1. npm install -g snyk
2. snyk auth
3. snyk test

Expected behavior

Remove the vulnerability reported by Snyk

Package

• I don't know. Or some 3rd-party package
• @nestjs/common
• @nestjs/core
• @nestjs/microservices
• @nestjs/platform-express
• @nestjs/platform-fastify
• @nestjs/platform-socket.io
• @nestjs/platform-ws
• @nestjs/testing
• @nestjs/websockets
• Other (see below)

Other package

No response

NestJS version

11.0.12

Packages versions

"dependencies": {
    "@nestjs/common": "11.0.12",
    "@nestjs/config": "4.0.2",
    "@nestjs/core": "11.0.12",
    "@nestjs/jwt": "11.0.0",
    "@nestjs/platform-express": "11.0.12",
    "@nestjs/swagger": "11.1.0",
  }

Node.js version

22.14.0

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

[houjuan0623]

same issue.

[mag123c]

From the documentation and source code, it seems that FileTypeValidator was intentionally designed to validate only the mimetype provided by the client, as a lightweight and naive validator — and that aligns with the comment that advises using magic-number-based validation for stronger security.
(#13311 (comment))

However, since this naive strategy can easily be bypassed (as Snyk pointed out), I was wondering:
Would it make sense to consider either:

• adding a more secure validator (e.g., MagicFileTypeValidator), or
• optionally supporting magic-number checks behind a flag or configuration?

Of course, this would require an external library like file-type, which may add a small dependency — but it would significantly improve validation reliability for those who need it.

If the core team feels this could be aligned with NestJS philosophy, I’d be happy to prepare a PR that keeps the default behavior as-is, but provides an optional secure validator for stricter use cases.

[kamilmysliwiec]

I guess we should either:

1. Remove this validator entirely, as it might create a false sense of security.
2. Use a more sophisticated validator (using an external library), as @mag123c suggested above.

Thoughts? If we go with removal, we'd need to deprecate it first, which would prolong the process. That said, I'm leaning toward option 2—for now.

[Chathula]

I also like to go forward with option 2 and would like to have it quick 😄

[Chathula]

@kamilmysliwiec @mag123c I filed a PR to introduce MagicFileTypeValidator . i am looking for feedback to improve this and merge quickly.

#14881

[norbornen]

Could you make a fix for nestjs v10?

[kamilmysliwiec]

Just FYI, this is not an issue.

1. This "vulnerability" is not a risk to any NestJS project that doesn't use FileTypeValidator (.addFileTypeValidator method)
2. The fact that FileTypeValidator does not check the file's content (magic number) but only the mimetype is (and always was):
   a) mentioned in the comment (description of the FileTypeValidator)
   b) mentioned in the docs (https://docs.nestjs.com/techniques/file-upload#file-validation)

There's really no need for any immediate fixes/patches/backfixes.

[Chathula]

Just FYI, this is not an issue.

1. This "vulnerability" is not a risk to any NestJS project that doesn't use FileTypeValidator (.addFileTypeValidator method)
2. The fact that FileTypeValidator does not check the file's content (magic number) but only the mimetype is (and always was):
   a) mentioned in the comment (description of the FileTypeValidator)
   b) mentioned in the docs (https://docs.nestjs.com/techniques/file-upload#file-validation)

There's really no need for any immediate fixes/patches/backfixes.

But the problem is that @nestjs/common has been marked as having moderate vulnerability. Because of that, if your pipeline has added a step to audit npm packages and fails if you have high or moderate vulnerabilities, this will be a blocker for these projects.

[kamilmysliwiec]

This is something that should be reported to Snyk, not us, though. The validator and the pipe work as described (in the documentation, in the comment block, and even the PR itself).