You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
form-data builds multipart/form-data request bodies. Through v4.0.5, the field name passed to FormData#append and the filename option are concatenated directly into the Content-Disposition header with no escaping of CR (\r), LF (\n), or ". An application that uses untrusted input as a field name or filename therefore lets an attacker terminate the header line and either inject additional headers or smuggle whole additional multipart parts into the request the application forwards to a backend.
This is CWE-93 (CRLF injection). It is a divergence from how browsers and the WHATWG HTML spec serialize form-data (they escape these characters), so the fix is to match that behavior. Severity is conditional: it depends on the consuming application passing attacker-controlled data as a field name or filename. Applications that only use fixed/trusted field names are not affected.
Details
In lib/form_data.js, _multiPartHeader builds the part header as:
and _getContentDisposition builds filename="' + filename + '"'. Neither escapes control characters, so a \r\n in field/filename ends the header line. The same applies to ", which can break out of the quoted parameter.
Before the fix this emits an injected X-Injected: true header line. A field name that also includes --<boundary> sequences can introduce additional parts (e.g. an extra name="is_admin" field), which a downstream parser accepts as legitimate.
Impact
For an application that uses untrusted field names/filenames:
Field injection / override (integrity). Inject or override fields the backend trusts (e.g. is_admin, role) — the primary demonstrated impact.
Header injection into the generated multipart part.
Claims of guaranteed privilege escalation, authentication bypass, high confidentiality impact, and availability impact are application-dependent downstream consequences, not properties of form-data itself, and are not demonstrated by the PoC.
Severity
The demonstrated, library-attributable impact is integrity (field/header injection); there is no demonstrated confidentiality disclosure or availability impact in form-data itself, and exploitation requires the consuming app to feed untrusted data into field names/filenames. A Moderate (≈5.3, I:L) rating is also defensible given that precondition.
Patch
Fixed in 4.0.6, 3.0.5, and 2.5.6. Users on older 0.x/1.x/2.x releases should upgrade to 2.5.6 or later.
The fix escapes \r, \n, and " as %0D, %0A, and %22 in field names and filenames, matching the WHATWG HTML multipart/form-data encoding algorithm that browsers implement. This neutralizes the injection while leaving ordinary field names (including name[0], dotted, and unicode names) unchanged.
Workaround
Until upgrading, validate or reject field names/filenames that contain control characters before calling append:
if(/[\r\n]/.test(field)){thrownewError('invalid field name');}
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
4.0.5→4.0.6form-data: CRLF injection in form-data via unescaped multipart field names and filenames
CVE-2026-12143 / GHSA-hmw2-7cc7-3qxx
More information
Details
Summary
form-databuildsmultipart/form-datarequest bodies. Through v4.0.5, thefieldname passed toFormData#appendand thefilenameoption are concatenated directly into theContent-Dispositionheader with no escaping of CR (\r), LF (\n), or". An application that uses untrusted input as a field name or filename therefore lets an attacker terminate the header line and either inject additional headers or smuggle whole additional multipart parts into the request the application forwards to a backend.This is CWE-93 (CRLF injection). It is a divergence from how browsers and the WHATWG HTML spec serialize form-data (they escape these characters), so the fix is to match that behavior. Severity is conditional: it depends on the consuming application passing attacker-controlled data as a field name or filename. Applications that only use fixed/trusted field names are not affected.
Details
In
lib/form_data.js,_multiPartHeaderbuilds the part header as:and
_getContentDispositionbuildsfilename="' + filename + '"'. Neither escapes control characters, so a\r\ninfield/filenameends the header line. The same applies to", which can break out of the quoted parameter.Proof of concept
Before the fix this emits an injected
X-Injected: trueheader line. A field name that also includes--<boundary>sequences can introduce additional parts (e.g. an extraname="is_admin"field), which a downstream parser accepts as legitimate.Impact
For an application that uses untrusted field names/filenames:
is_admin,role) — the primary demonstrated impact.Claims of guaranteed privilege escalation, authentication bypass, high confidentiality impact, and availability impact are application-dependent downstream consequences, not properties of
form-dataitself, and are not demonstrated by the PoC.Severity
The demonstrated, library-attributable impact is integrity (field/header injection); there is no demonstrated confidentiality disclosure or availability impact in
form-dataitself, and exploitation requires the consuming app to feed untrusted data into field names/filenames. A Moderate (≈5.3,I:L) rating is also defensible given that precondition.Patch
Fixed in 4.0.6, 3.0.5, and 2.5.6. Users on older 0.x/1.x/2.x releases should upgrade to 2.5.6 or later.
The fix escapes
\r,\n, and"as%0D,%0A, and%22in field names and filenames, matching the WHATWG HTMLmultipart/form-dataencoding algorithm that browsers implement. This neutralizes the injection while leaving ordinary field names (includingname[0], dotted, and unicode names) unchanged.Workaround
Until upgrading, validate or reject field names/filenames that contain control characters before calling
append:Credit
Reported by yueyueL.
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
form-data/form-data (form-data)
v4.0.6Compare Source
Commits
"in field names and filenames8dff42c@ljharb/eslint-config,auto-changelog,tapef31d21ehasown,mime-types92ae0ebjs-randomness-predictor67b0f65Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.