CVE-2025-7783: Critical form-data Unsafe Randomness Vulnerability Fixed

Severity: 🔴 CRITICAL | Package: form-data | Fixed In: 2.5.4, 3.0.4, 4.0.4

Introduction

If your Node.js application submits forms, uploads files, or communicates with APIs using multipart data, there is a very good chance you depend on the form-data package — either directly or as a transitive dependency. With tens of millions of weekly downloads on npm, form-data is one of the most quietly essential libraries in the JavaScript ecosystem.

On the surface, it does something deceptively simple: it constructs multipart/form-data payloads, the same format your browser uses when you upload a file through an HTML form. But buried in that simplicity was a critical security flaw — the library was using an unsafe, non-cryptographic random function to generate the boundary strings that separate multipart fields.

This vulnerability, tracked as CVE-2025-7783, has been rated CRITICAL in severity. In this post, we'll break down exactly what went wrong, how it could be exploited, and what you need to do to protect your applications.

Background: What Is form-data?

The form-data npm package is a Node.js implementation of the multipart/form-data specification defined in RFC 7578. It is used to programmatically construct form submissions — particularly for file uploads — in environments where a browser is not present.

You'll find it as a direct or indirect dependency in packages like:
- axios
- node-fetch
- superagent
- request (deprecated but still widely used)
- Countless internal API clients and SDKs

A typical usage looks like this:

const FormData = require('form-data');
const fs = require('fs');

const form = new FormData();
form.append('username', 'alice');
form.append('avatar', fs.createReadStream('/path/to/avatar.png'));

// The resulting HTTP body looks something like:
// --abc123randomBoundary456xyz
// Content-Disposition: form-data; name="username"
//
// alice
// --abc123randomBoundary456xyz
// Content-Disposition: form-data; name="avatar"; filename="avatar.png"
// Content-Type: image/png
//
// <binary data>
// --abc123randomBoundary456xyz--

That abc123randomBoundary456xyz string is the boundary — a delimiter that tells the server where one field ends and the next begins. The security of multipart parsing depends heavily on this boundary being unpredictable.

The Vulnerability Explained

What Went Wrong: Predictable Boundaries

The core of CVE-2025-7783 is straightforward but serious: form-data was using Math.random() to generate multipart boundary strings instead of a cryptographically secure random number generator (CSPRNG).

Here's a simplified illustration of what the vulnerable code likely looked like:

// ❌ VULNERABLE: Using Math.random() — NOT cryptographically secure
function generateBoundary() {
  let boundary = '--------------------------';
  for (let i = 0; i < 24; i++) {
    boundary += Math.floor(Math.random() * 10).toString(10);
  }
  return boundary;
}

And what a secure implementation should look like:

// ✅ SECURE: Using crypto.randomBytes() — cryptographically secure
const crypto = require('crypto');

function generateBoundary() {
  return `----FormBoundary${crypto.randomBytes(16).toString('hex')}`;
}

Why Does Math.random() Matter Here?

Math.random() is designed for statistical randomness — things like shuffling a deck of cards in a game or picking a random color for a UI element. It is explicitly not designed for security purposes.

Here's why it falls short:

The V8 JavaScript engine (used by Node.js) implements Math.random() using an algorithm called xorshift128+. While it produces numbers that look random, a determined attacker who can observe a few outputs from Math.random() can reconstruct the internal state of the PRNG and predict all future outputs.

This is not theoretical — tools like Practical Predictability of Math.random() demonstrate exactly this attack.

Real-World Attack Scenarios

Scenario 1: Boundary Injection / Pollution

If an attacker can predict the boundary string before a request is sent, they may be able to craft malicious input data that contains the boundary string. When the server parses the multipart body, it would interpret the injected boundary as a real delimiter, potentially:

• Splitting a single field into multiple fields
• Injecting additional form fields the application never intended to send
• Overwriting legitimate field values (e.g., injecting admin=true after a role=user field)

# Attacker knows the boundary will be: ----FormBoundary1234567890

# Malicious input in a "comment" field:
Hello World
----FormBoundary1234567890
Content-Disposition: form-data; name="role"

admin
----FormBoundary1234567890--

# Server parses this as TWO fields: "comment" AND "role=admin"

Scenario 2: Security Token Exposure via Timing Attacks

In applications where the boundary is logged, transmitted over a side channel, or otherwise observable, an attacker could use the predictability of Math.random() to correlate requests, de-anonymize users, or link together supposedly independent sessions.

Scenario 3: CSRF Token Bypass in Multipart Forms

Some CSRF protection schemes rely on the unpredictability of multipart boundaries as an additional layer of security (the "secret" is that only the legitimate origin can construct a valid multipart body). A predictable boundary undermines this assumption entirely.

Scenario 4: File Upload Manipulation

In systems that process file uploads, a predictable boundary could allow an attacker to manipulate the parsing of a file's binary content — particularly if the file itself is attacker-controlled — causing the server to misinterpret where the file data ends and metadata begins.

The Fix

What Changed

The maintainers of form-data released patched versions across all actively supported major version lines:

The fix replaces the use of Math.random() with Node.js's built-in crypto module, specifically crypto.randomBytes(), which draws entropy from the operating system's CSPRNG (/dev/urandom on Linux/macOS, BCryptGenRandom on Windows).

Before vs. After

Before (Vulnerable):

// Using Math.random() — output is predictable
FormData.prototype._generateBoundary = function() {
  var boundary = '--------------------------';
  for (var i = 0; i < 24; i++) {
    boundary += Math.floor(Math.random() * 10).toString(10);
  }
  this._boundary = boundary;
};

After (Secure):

// Using crypto.randomBytes() — output is cryptographically unpredictable
const crypto = require('crypto');

FormData.prototype._generateBoundary = function() {
  this._boundary = `----FormBoundary${crypto.randomBytes(16).toString('hex')}`;
};

With crypto.randomBytes(16), the boundary contains 128 bits of cryptographically secure entropy. An attacker would need to make 2¹²⁸ guesses on average to predict it — effectively impossible with current technology.

How This Was Applied in the PR

The fix was applied by updating webui/package.json and the corresponding webui/yarn.lock to pin form-data to the patched versions. Because form-data is often a transitive dependency (pulled in by other packages), the yarn.lock update ensures that all resolution paths — regardless of which parent package requested form-data — resolve to the secure version.

// webui/package.json (conceptual — ensuring patched versions)
{
  "resolutions": {
    "form-data": "^4.0.4"
  }
}

Using resolutions (in Yarn) or overrides (in npm 8+) is a powerful technique to force all transitive dependencies to use a specific patched version of a package, even when the direct dependency hasn't updated their own package.json yet.

Conclusion

CVE-2025-7783 is a textbook example of a subtle but critical security mistake: using the wrong tool for the job. Math.random() is a perfectly fine function for non-security use cases, but its use in generating multipart boundaries — values that need to be unpredictable to maintain the integrity of HTTP requests — introduced a critical vulnerability into one of npm's most downloaded packages.

The fix is straightforward (swap Math.random() for crypto.randomBytes()), but the lesson is broad: cryptographic security requires cryptographic tools. Non-cryptographic PRNGs have no place in security-sensitive code paths, and it's the responsibility of both library authors and application developers to know the difference.

Key Takeaways:

1. ✅ Upgrade immediately: Update form-data to 2.5.4, 3.0.4, or 4.0.4 depending on your version
2. ✅ Audit transitive dependencies: You are responsible for the security of every package in your node_modules, not just the ones you directly import
3. ✅ Use CSPRNGs for security: crypto.randomBytes() and crypto.randomUUID() are your friends
4. ✅ Automate vulnerability detection: Make dependency scanning a standard part of your CI/CD pipeline
5. ✅ Learn the patterns: CWE-338 and similar weaknesses appear across all languages and frameworks — learn to recognize them

Security is a team sport. Keep your dependencies updated, keep scanning, and keep learning.

This fix was automatically detected and remediated by OrbisAI Security. Automated security tooling identified the vulnerable form-data version via Trivy scanning and determined the appropriate patches — demonstrating how automation can dramatically reduce the window of exposure for known CVEs.

References:
- CVE-2025-7783 – NVD
- form-data on npm
- CWE-338: Use of Cryptographically Weak PRNG
- Node.js Crypto Documentation
- OWASP Top 10: A02 Cryptographic Failures
- RFC 7578: Returning Values from Forms: multipart/form-data