File validation fails with MagicNumbersValidation

[alumni]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

I'm starting to get this error after updating from 10.4.15 to 10.4.17:

Validation failed (current file type is application/octet-stream, expected type is application/octet-stream)

Introduced in PR #14948 / #14881.

Minimum reproduction code

n/a

Steps to reproduce

async uploadFile(
  @UploadedFile(
    new ParseFilePipe({
      validators: [
        new FileTypeValidator({
          fileType: 'application/octet-stream',
          // skipMagicNumbersValidation: true,
        }),
      ],
    }),
  )
  file: Express.Multer.File,
  @Body() body: BodyDto,
) { ... }

Expected behavior

I would expect that 'application/octet-stream' === 'application/octet-stream' and the validation does not fail.

Workaround: set skipMagicNumbersValidation: true.

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

10.4.17

Packages versions

[System Information]
OS Version     : macOS 24.3.0
NodeJS Version : v20.19.0
PNPM Version    : 9.15.9 

[Nest CLI]
Nest CLI Version : 10.4.9 

[Nest Platform Information]
platform-express version : 10.4.17
cache-manager version    : 2.3.0
bull-shared version      : 11.0.2
schematics version       : 10.2.3
schedule version         : 5.0.1
terminus version         : 11.0.0
swagger version          : 7.4.2
typeorm version          : 11.0.0
testing version          : 10.4.17
bullmq version           : 11.0.2
common version           : 10.4.17
config version           : 4.0.2
axios version            : 4.0.0
core version             : 10.4.17
mailer version           : 2.0.2

Node.js version

20.19.0

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

[barth-b]

+1

[joe-reed]

Have also been seeing this in jest tests.

In my case logging out the error in

nest/packages/common/pipes/file/file-type.validator.ts

Lines 62 to 64 in 86eb46d

	} catch {
	return false;
	}

revealed the issue was TypeError: A dynamic import callback was invoked without --experimental-vm-modules. Adding that flag to the node options (as per https://jestjs.io/docs/ecmascript-modules) got my test passing. Not an ideal solution though

[alumni]

Have also been seeing this in jest tests.

I have it in production, not in tests.

[mag123c]

I've submitted a PR to address this issue: FileTypeValidator now supports fallback to mimetype.

Introduces a fallbackToMimetype option to allow validation to pass when:

• Magic number detection fails (e.g., small/plaintext files like .txt, .csv)
• The provided mimetype still matches the expected type

Also improves buildErrorMessage() to provide clearer debugging messages.

I also ran into this issue myself, and the misleading error message made it harder to diagnose initially.

If this change gets merged into the main branch, I’ll prepare a backport PR for 10.4.17.

Let me know if anything else is needed!

[kamilmysliwiec]

Let's track this here #14995

[yedlosh]

@mag123c Hi 👋 I don't think the fallback to mimetype fixes the 'dynamic import callback' issue, as already tracked again in #15055.
It obfuscates the ESM issue further as it's now possible to get an error like:
'Validation failed (current file type is image/png, expected type is image/png) - magic number detection failed, used mimetype fallback'

[mag123c]

@yedlosh
Thanks for your valuable feedback! You're absolutely right that PR #14995 (the fallbackToMimetype feature) doesn't fix the 'dynamic import callback' issue tracked in #15055, nor was it intended to.
My PR aimed to address #14977 by providing an optional fallback for files where magic number detection is inherently unreliable (like .txt, .csv), assuming file-type itself loads correctly.
I agree that if the underlying file-type import fails due to the ESM issue, the fallback message could indeed obscure the root cause, making debugging harder. To that end, perhaps the validator's error handling could be enhanced. Specifically, it might be beneficial if it could explicitly signal when the file-type module itself fails to load (which would more directly point towards the ESM/loadEsm issue), as distinct from when file-type (after successfully loading) simply cannot determine a magic number for a given buffer. This would provide clearer, more actionable error messages for developers facing the loadEsm problem.