The vulnerability in @fastify/busboy isn't a parser bug — it's a downstream trust assumption that the CVSS score fundamentally misrepresents. The library is behaving correctly per HTTP spec: it preserves what it finds in header values. The actual risk only materializes when your application takes that parsed filename or field name and passes it to a CR/LF-sensitive operation — writing to a log file, forwarding in an HTTP response header, or using it in a filesystem operation — without sanitization.
A consumer that immediately strips CR/LF from parsed header values faces near-zero risk from this issue. A consumer that treats the parsed value as trusted input faces critical exposure. This is why the CVSS 5.8 is analytically weak — it scores the vulnerability at the library layer where the impact is theoretical, but the real blast radius is downstream in however your application handles the parsed data.
The 3.2.2 fix changes the library's implicit contract. Instead of silently passing through malformed headers, it now rejects them. This is the right security posture, but it will break existing applications that were legitimately uploading multipart parts with encoded or non-ASCII characters in field names. When you upgrade, legitimate uploads may start failing with rejection errors — and developers under pressure will often add workarounds that reintroduce the hazard, either by pre-stripping the check or by monkey-patching the rejection behavior back to passthrough.
The dependency propagation compounds the problem. @fastify/multipart and similar consumers need to explicitly bump their @fastify/busboy dependency to pull in the fix, and any forked, vendored, or copy-pasted parser logic will never see the update. Dependency scanners will show you're on 3.2.2 while your实际运行的代码 may be running something else entirely.
What you should do: audit every place your application consumes parsed multipart values — filenames, field names, content-type parameters. If any of those flow to logging, HTTP headers, or filesystem operations without sanitization, that's your real exposure. Decide whether your pipeline can tolerate the 3.2.2 rejection behavior before upgrading, and plan for the debugging cycle when legitimate uploads with unusual encodings start failing.