CVE-2025-7783

What it actually does

The flaw is in the Node.js form-data library's multipart/form-data generation logic, specifically its use of insufficiently random values when creating multipart boundaries in lib/form_data.js. If an attacker can predict or influence multipart boundary values and cause an application to generate outbound multipart HTTP requests with attacker-controlled field names or values, they may be able to craft data that is parsed by a downstream server as additional or altered HTTP parameters. The resulting impact is HTTP Parameter Pollution, potentially changing server-side interpretation of request parameters and affecting confidentiality or integrity of downstream transactions. Exploitation is network-reachable but has high attack complexity because it depends on application-specific data flow, multipart parsing behavior, and whether untrusted input is embedded into generated form-data requests.

Why it matters to the business

Applications that use vulnerable versions of form-data to submit multipart requests to APIs, identity systems, payment services, upload handlers, or internal backends may be exposed to request tampering if attacker-controlled data is relayed through those requests. Successful exploitation could allow business logic bypass, incorrect transaction processing, unauthorized parameter changes, or leakage of sensitive data handled by downstream services. The issue is not listed in CISA KEV, is not associated with ransomware use, and has a low EPSS score of 0.01735 with no known exploit maturity reported, so it is lower urgency than actively exploited internet-facing flaws; however, form-data is a common transitive dependency in Node.js ecosystems, so organizations should prioritize broad dependency inventory and routine upgrade campaigns.

How an attack unfolds

An attacker first identifies an application path that accepts attacker-controlled input and later uses the form-data library to construct a multipart/form-data request to another service. The attacker then studies or infers how multipart boundaries are generated by the vulnerable library version and crafts input designed to collide with or manipulate multipart parsing. If the generated boundary can be predicted or the payload can be shaped to introduce ambiguous multipart content, the downstream recipient may interpret the request as containing extra, duplicated, or modified parameters. The attacker uses this parameter pollution to alter application behavior, such as changing a submitted value, overriding a security-relevant parameter, injecting an unexpected field, or causing mismatched validation between the originating application and the downstream service. Practical exploitation is highly context-dependent and generally requires a vulnerable data flow where untrusted input is forwarded in multipart requests and the receiving service handles duplicate or ambiguous parameters insecurely.

How to fix it

Upgrade form-data to a fixed release line. Affected versions are form-data versions earlier than 2.5.4, versions 3.0.0 through 3.0.3, and versions 4.0.0 through 4.0.3. Use 2.5.4 or later on the 2.x line, 3.0.4 or later on the 3.x line, or 4.0.4 or later on the 4.x line where available, or vendor a version containing upstream commit 3d1723080e6577a66f17f163ecd345a21d8d0fd0. Because form-data is frequently pulled in transitively, update package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, and container images rather than only editing top-level package.json. If immediate upgrade is not possible, reduce exposure by preventing untrusted input from being embedded verbatim into multipart field names, filenames, headers, or values; reject CRLF and multipart boundary-like sequences in user-controlled fields; enforce allowlists for outbound parameters; and make downstream services reject duplicate parameters or ambiguous multipart bodies.

How to confirm the fix worked

Confirm that dependency resolution no longer includes vulnerable form-data versions. Run package inventory commands such as npm ls form-data, yarn why form-data, or pnpm why form-data, and verify all resolved instances are 2.5.4 or later, 3.0.4 or later, or 4.0.4 or later. Inspect lockfiles and built artifacts for vulnerable versions, especially in bundled serverless packages and container images. Validate runtime behavior by exercising workflows that generate multipart/form-data requests and confirming boundaries are generated safely after upgrade. Add regression tests that submit user input containing duplicate parameter names, CRLF characters, and boundary-like strings, then verify downstream services do not receive unexpected additional fields or altered values.

Typical attack path

1. Identify a Node.js application or service that depends on a vulnerable form-data version: earlier than 2.5.4, 3.0.0 through 3.0.3, or 4.0.0 through 4.0.3.
2. Find an endpoint or workflow where attacker-supplied input is incorporated into an outbound multipart/form-data request generated by that dependency.
3. Infer or predict the multipart boundary behavior used by the vulnerable library version.
4. Craft input containing boundary-like content, duplicate parameter names, or multipart control sequences intended to alter downstream parsing.
5. Submit the crafted request to the originating application so it relays a polluted multipart request to a downstream service.
6. Abuse the downstream service's interpretation of duplicated or injected parameters to modify request semantics, bypass validation, or access unintended data.
7. Repeat and tune the payload based on observable application responses, downstream errors, or side effects.

How to detect it

There are no known universal compromise indicators for this library flaw because exploitation depends on how an individual application uses form-data and how downstream services parse multipart requests. To assess possible prior exploitation, review HTTP access logs, API gateway logs, reverse proxy logs, application logs, and downstream service logs for multipart/form-data requests containing duplicate parameter names, unexpected extra fields, malformed multipart boundaries, CRLF sequences in submitted values, or parser errors around upload and form-submission workflows. Pay particular attention to requests that produce downstream validation mismatches, 400-series multipart parsing errors, unusual 500-series exceptions, or business-logic changes inconsistent with the originating request. If request bodies are logged in a secure and compliant manner, search for user-controlled values containing multipart boundary markers, embedded Content-Disposition headers, or repeated security-sensitive parameters. Correlate suspicious requests with subsequent account changes, transaction changes, file uploads, privilege changes, or API calls that would indicate parameter tampering. Absence of these artifacts does not prove non-exploitation because many deployments do not retain multipart bodies.

What your security team should do

• Inventory all Node.js applications, build artifacts, and containers for direct or transitive use of form-data versions earlier than 2.5.4, 3.0.0 through 3.0.3, and 4.0.0 through 4.0.3.
• Prioritize upgrades for services that accept external input and forward that input in multipart/form-data requests to sensitive downstream systems such as authentication, authorization, payment, document upload, or administrative APIs.
• Update dependency lockfiles and rebuild/redeploy affected applications; do not rely only on source manifest changes.
• Where dependency updates are delayed, add input validation for multipart-related metacharacters and enforce strict downstream duplicate-parameter handling.
• Review access logs, application logs, API gateway logs, and downstream service logs for suspicious multipart requests, duplicate parameters, parser errors, or boundary-like payloads in user-controlled fields.
• Add software composition analysis checks to CI/CD to block vulnerable form-data versions from being reintroduced.
• Because there is no KEV listing, no ransomware association, and low EPSS, handle through prioritized patch management rather than emergency incident response unless suspicious multipart activity is observed.