[Copilot]

@fastify/busboy@2.1.1 can throw on prototype-named multipart headers, causing denial of service (GHSA-x8mw-p69m-v3mx). Version 3.2.1 patches the parser.

• Dependency update

  • Add an Undici-scoped npm override pinning Busboy to 3.2.1; regenerate the lockfile without changing other dependency versions.
  • Leave the tracked bundle unchanged: it contains neither Busboy nor Undici.

• Reachability Assessment

  • High confidence: not reachable locally. Undici’s multipart formData() parser invokes Busboy, but the local action never calls this API or accepts inbound multipart requests.
  • The public composite action delegates externally; that dependency tree is outside this assessment.
  • Primarily scanner remediation, not demonstrated active exposure.

• Validation

  • Build, type checking, formatting, and multipart field/file parsing passed, including __proto__ and constructor headers.
  • Existing blockers: Jest is absent and the lint configuration is missing. PR CI awaits approval.

Original prompt

---

This section details the Dependabot vulnerability alert you should resolve

<alert_title>@fastify/busboy vulnerable to Denial of Service via prototype-named multipart part header</alert_title>
<alert_description>### Impact

Versions of @fastify/busboy from 1.0.0 and prior to 3.2.1 are vulnerable to a Denial of Service. The multipart header parser stores part-header names on a plain JavaScript object, so a part header named __proto__ or constructor resolves to an inherited value that is not an array, and the parser throws TypeError: this.header[h].push is not a function. Through the documented req.pipe(busboy) integration this surfaces as an error event, while direct write()/end() usage throws synchronously and can terminate the Node.js process if uncaught. The parser runs before application middleware, so any unauthenticated client that can submit multipart/form-data is affected.

Patches

Fixed in version 3.2.1.

Workarounds

Attach an error listener to the Busboy stream so the parser failure is handled rather than crashing the process, and wrap direct write()/end() calls in a try/catch. Upgrading to 3.2.1 removes the failure entirely.</alert_description>

high
GHSA-x8mw-p69m-v3mx, CVE-2026-19481
@fastify/busboy
npm
<vulnerable_versions>2.1.1</vulnerable_versions>
<patched_version>3.2.1</patched_version>
<manifest_path>.github/action/package-lock.json</manifest_path>

https://github.com/fastify/busboy/security/advisories/GHSA-x8mw-p69m-v3mx https://nvd.nist.gov/vuln/detail/CVE-2026-19481 https://github.com/fastify/busboy/commit/957a24b66d5915e6d0a6ac988c9dbcee86373e9b https://cna.openjsf.org/security-advisories.html https://github.com/fastify/busboy/releases/tag/v3.2.1 https://github.com/advisories/GHSA-x8mw-p69m-v3mx

<task_instructions>Resolve this alert by updating the affected package to a non-vulnerable version. Prefer the lowest non-vulnerable version (see the patched_version field above) over the latest to minimize breaking changes. Include a Reachability Assessment section in the PR description. Review the alert_description field to understand which APIs, features, or configurations are affected, then search the codebase for usage of those specific items. If the vulnerable code path is reachable, explain how (which files, APIs, or call sites use the affected functionality) and note that the codebase is actively exposed to this vulnerability. If the vulnerable code path is not reachable, explain why (e.g. the affected API is never called, the vulnerable configuration is not used) and note that the update is primarily to satisfy vulnerability scanners rather than to address an active risk. If the advisory is too vague to determine reachability (e.g. 'improper input validation' with no specific API named), state that reachability could not be determined and explain why. Include a confidence level in the reachability assessment (e.g. high confidence if the advisory names a specific API and you confirmed it is or is not called, low confidence if the usage is indirect and hard to trace). If no patched version is available, check the alert_description field for a Workarounds section — the advisory may describe configuration changes or usage patterns that mitigate the vulnerability without a version update. If a workaround is available, apply it and leave a code comment referencing the advisory identifier explaining it is a temporary mitigation. If neither a patch nor a workaround is available, explain in the PR description why the alert cannot be resolved automatically so a human reviewer can take over. Inspect the repository to determine which package manager is used (e.g. lock files, config files, build scripts) and use that tooling to perform the update — do not edit lock files directly. If the version constraint in the manifest (e.g. package.json, Gemfile, pyproject.toml) caps the version below the fix, update the constraint first. For transitive dependencies, determine whether it is simpler to update the direct dependency that pulls in the vulnerable package or to update the transitive dependency directly, and choose the least disruptive approach. If upgrading to fix the vulnerability forces a major version bump or known breaking changes, review the changelog or release notes, then audit the codebase for usage of affected APIs and fix any breaking changes that are found. If the package manager fails to resolve dependencies (e.g. peer dependency conflicts, incompatible engine constraints), document the error in the PR description rather than attempting increasingly complex workarounds. After updating, check the lock file to confirm the package no longer resolves to a version in the vulnerable range. Keep changes minimal and tightly scoped. Ensure tests, build, type checking, and l...

• Resolves advanced-security/codeql-extractor-iac alert [Feat]: Azure DepOps Pipelines #42

[Copilot]

🟢 Approval recommended

No active review issues are reported for the scoped Busboy dependency update.

No open issues 🎉

1 file not reviewed

• .github/action/package-lock.json: Generated file

What changed in this PR

Updates the local GitHub Action’s transitive @fastify/busboy dependency to 3.2.1 to address GHSA-x8mw-p69m-v3mx. The PR describes this as scanner remediation because the affected multipart parser is not reachable locally.

Changes:

• Adds an Undici-scoped npm override pinning Busboy to 3.2.1.
• Updates both lockfile dependency records without changing unrelated dependency versions.
• Leaves the tracked bundle unchanged because it contains neither Busboy nor Undici.

File	Description
.github/​action/​package.json	Adds the Undici-scoped Busboy override.
.github/​action/​package-lock.json	Records Busboy 3.2.1, its integrity hash, and the overridden dependency requirement.

_{Review effort: Balanced}

[github-actions]

Dependency Review

The following issues were found:

• ❌ 1 vulnerable package(s)
• ✅ 0 package(s) with incompatible licenses
• ✅ 0 package(s) with invalid SPDX license definitions
• ✅ 0 package(s) with unknown licenses.

See the Details below.

Snapshot Warnings

⚠️: No snapshots were found for the head SHA 5f70228.

Ensure that dependencies are being submitted on PR branches and consider enabling retry-on-snapshot-warnings. See the documentation for more information and troubleshooting advice.

Vulnerabilities

.github/action/package-lock.json

Name	Version	Vulnerability	Severity
@fastify/busboy	3.2.1	@fastify/busboy vulnerable to CRLF injection via multipart Content-Disposition filename and name	moderate

OpenSSF Scorecard

Package	Version	Score	Details
npm/@fastify/busboy	3.2.1	Unknown	Unknown

Scanned Files

• .github/action/package-lock.json