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).

[boris-bojic-pid]

FYI - It's not only reported in synk, but also the github dependabot, as well as the npm / yarn audit, which blocks our pipeline at the moment.

[xadamxk]

This vulnerability was blocking our ability to deploy via our quality-gated pipeline.
I'm hoping the fix for this is merged and release soon so others don't run into similar issues.

Follow along here: #14881

[kamilmysliwiec]

v11.0.16 has been published

[axi92]

Does this fix GHSA-cj7v-w2c7-cp7c ?

[kamilmysliwiec]

Correct

[xadamxk]

Аre you planning to release a fix for v10?

@norbornen
Yes, you can follow 10.x changes here: #14948

[TaxBusby]

It's ridiculous that Snyk and Github are calling this "Arbitrary code injection". The Github advisory summary reads "nest allows a remote attacker to execute arbitrary code via the Content-Type header" which seems very misleading to me.

[kamilmysliwiec]

@TaxBusby the classification is indeed very deceptive