---
id: "CVE-2026-117531"
kind: "vulnerability"
aliases: ["CVE-2026-117531"]
title: "@fastify/multipart: malformed upload leaves requests hanging, exhausting server connections"
severity: "medium"
cvss: 5.9
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["fastify", "file-upload", "node", "npm", "package"]
not_affected_if: ["immediate-file-consumption", "not-using-multipart", "version-10.1.7-or-later"]
published_at: "2026-11-02T11:17:30+00:00"
first_seen_at: "2026-11-02T11:22:53+00:00"
updated_at: "2026-11-02T11:24:16+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-117531", "first_seen_at": "2026-11-02T11:22:53+00:00"}]
---

# @fastify/multipart: malformed upload leaves requests hanging, exhausting server connections

A malformed multipart upload with no closing boundary makes the Fastify multipart plugin drop the file stream without an error, so handlers that consume the file later never finish. An unauthenticated remote client can repeat these requests to pile up open connections and exhaust server resources.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the installed version with `npm ls @fastify/multipart`
- Look for routes that iterate request parts with `request.parts()` or `request.file()` and do asynchronous work before reading the file stream

## Fix

- `@fastify/multipart` `10.1.7` or later

## Timeline

- 2026-11-02T11:22:53+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-117531

## Documents

- [advisory] Vendor advisory: github.com https://github.com/fastify/fastify-multipart/security/advisories/GHSA-5849-5m6q-9632

## From the sources

@fastify/multipart is the multipart form-data and file upload plugin for the Fastify web framework. In versions 5.3.0 through 10.1.6, the plugin does not propagate a parser error to the file stream when a request body ends inside a file part with no closing boundary, even though the Content-Length is complete, the client does not abort, and no file size limit is exceeded. The plugin destroys the in-progress file stream without an error, so a handler that iterates the request parts and performs asynchronous work before consuming the file attaches to a stream that never emits an error or end event, and the request never responds while the connection stays open. An unauthenticated remote client can repeat these malformed uploads against such a route to accumulate pending connections and exhaust server resources, so the impact is availability only and exploitation depends on the application using a delayed file consumer. The issue is fixed in @fastify/multipart 10.1.7, where the parser error is propagated to the file stream so a delayed consumer settles with an error instead of hanging, and users should upgrade to 10.1.7 or later. There is no workaround other than upgrading.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_