How Unsafe Random Number Generation in form-data Compromises Multipart Form Security and How to Fix It

Understanding the Vulnerability

What Happened

In a recent security audit, a critical vulnerability (CVE-2025-7783) was identified in the form-data npm package, a widely-used library for handling multipart/form-data submissions in Node.js applications. The vulnerability stems from the use of an unsafe random number generation algorithm when creating multipart form boundaries—the delimiters that separate different fields in HTTP multipart requests.

The affected versions were:
- form-data 4.0.5 (and earlier 4.x versions)
- form-data 3.0.x (prior to 3.0.4)
- form-data 2.x (prior to 2.5.4)

This vulnerability affects any Node.js application that constructs multipart form data for file uploads, API requests, or form submissions using this library.

The Technical Problem

When form-data creates a multipart request, it generates a unique boundary string to separate form fields. This boundary is critical to the integrity of the request—it tells the server where one field ends and another begins.

The vulnerable code pattern used insufficiently random values for boundary generation. Instead of using cryptographically secure randomness (via Node.js's crypto module), the library relied on a weaker random algorithm that could be predicted by an attacker.

Here's why this matters:

1. Predictable Boundaries: An attacker can calculate or guess the boundary value that your application will use
2. Form Data Injection: With a known boundary, an attacker can craft a multipart payload that includes extra fields or malicious data
3. Server-Side Bypass: If the server validates the boundary format weakly, an attacker could inject additional form fields that bypass validation logic

The Attack Scenario

Imagine an application that uses form-data to upload a user profile picture:

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

// Vulnerable code path (form-data 4.0.5)
const form = new FormData();
form.append('username', 'alice');
form.append('file', fs.createReadStream('profile.jpg'));

// The boundary generated by form-data 4.0.5 could be predicted
// Example: ----WebKitFormBoundary7MA4YWxkTrZu0gW (weak randomness)

An attacker monitoring network traffic could:
1. Observe the boundary value used in previous requests
2. Predict the next boundary value based on the weak random algorithm
3. Craft a malicious multipart payload with the predicted boundary:
```
------PredictedBoundary123
Content-Disposition: form-data; name="username"

alice
------PredictedBoundary123
Content-Disposition: form-data; name="admin"

true
------PredictedBoundary123--
`` 4. Inject theadmin=true` field into the form submission, potentially elevating privileges if the server doesn't validate field names strictly

The Fix in Detail

What Changed

The fix involved upgrading form-data to versions that implement cryptographically secure random boundary generation. The upgrade also updated critical dependencies:

Before (Vulnerable):

"form-data": "4.0.5"
"hasown": "^2.0.2"
"mime-types": "^2.1.12"

After (Secure):

"form-data": "4.0.6"
"hasown": "^2.0.4"
"mime-types": "^2.1.35"

The Specific Changes

Looking at the package-lock.json diff:

1. form-data upgraded from 4.0.5 to 4.0.6
   - Integrity hash changed from sha512-8RipRLol37bNs2bhoV67fiTEvdTrbMUYcFTiy3+wuuOnUog2QBHCZWXDRijWQfAkhBj2Uf5UnVaiWwA5vdd82w== to sha512-vKatAh4SlVfgbv+YtmhiRjhEMJsYpsG1Y2rMQtR+SVSbytsSD1YGzDIcrAJmdFec88u/+VoGmxnl+80gL1tRCQ==
   - This indicates substantial code changes to the boundary generation logic

2. hasown updated from 2.0.2 to 2.0.4
   - hasown is a utility library used by form-data for property checking
   - The update ensures compatibility with the new randomness implementation

3. mime-types updated from 2.1.12 to 2.1.35
   - Updated to the latest stable version with security patches

4. Removal of nested form-data in request dependency
   - The diff shows removal of form-data 2.3.3 from the request package's node_modules
   - This eliminates a potential transitive vulnerability path

How It Fixes the Problem

The patched versions implement cryptographically secure random boundary generation using Node.js's native crypto module:

Secure boundary generation pattern (conceptual):

// Secure approach (form-data 4.0.6+)
const crypto = require('crypto');

function generateBoundary() {
  // Use crypto.randomBytes() for cryptographic randomness
  return 'WebKitFormBoundary' + crypto.randomBytes(16).toString('hex');
}

// Example output: WebKitFormBoundaryf7e3a9c2d5b1e4a6c8f2b9d3e1a5c7f9
// Nearly impossible to predict

This ensures:
- Unpredictability: Each boundary is cryptographically random and unique
- Entropy: 128 bits of randomness (16 bytes × 8 bits) makes brute-force attacks infeasible
- No Patterns: No mathematical relationship between consecutive boundaries

Prevention & Best Practices

For Developers Using form-data

1. Update Immediately: Ensure your project uses form-data 4.0.6+, 3.0.4+, or 2.5.4+
   bash npm update form-data

2. Verify Dependencies: Check for transitive dependencies that might pull in vulnerable versions
   bash npm ls form-data npm audit

3. Lock Your Dependencies: Use package-lock.json or yarn.lock to ensure consistent versions across environments

For Security-Sensitive Code

When working with sensitive operations that require randomness:

1. Always Use Crypto Randomness: Never use Math.random() for security purposes
   ```javascript
   // ❌ Bad
   const boundary = '----' + Math.random().toString(36);

// ✅ Good
const crypto = require('crypto');
const boundary = '----' + crypto.randomBytes(16).toString('hex');
```

1. Validate Boundaries Server-Side: Even with secure boundaries, validate that received boundaries match expected patterns
   javascript const validBoundaryRegex = /^[a-zA-Z0-9\-_]{20,}$/; if (!validBoundaryRegex.test(receivedBoundary)) { throw new Error('Invalid boundary format'); }

2. Use Security Scanning: Integrate tools into your CI/CD pipeline
   bash npm audit trivy scan package-lock.json

Industry Standards

• CWE-330: Use of Insufficiently Random Values
• OWASP A02:2021: Cryptographic Failures
• NIST SP 800-38B: Recommendation for Block Cipher Modes of Operation

Key Takeaways

• Multipart boundaries are security-critical: They delimit form fields and must be unpredictable to prevent data injection attacks
• Math.random() is never secure: JavaScript's Math.random() has insufficient entropy for any security purpose; always use crypto.randomBytes() or crypto.getRandomValues()
• Dependency chains matter: form-data's vulnerability affected any application using it for file uploads, including transitive dependencies through packages like request
• Automated detection works: Trivy and npm audit successfully flagged this vulnerability, enabling quick identification and patching
• Update your dependencies regularly: This fix required updating not just form-data but also hasown and mime-types to ensure compatibility and eliminate related attack vectors

How Orbis AppSec Detected This

Source: The vulnerability enters through the form-data package's boundary generation logic, which is called whenever a multipart form request is constructed in any Node.js application using this library.

Sink: The unsafe random function call in form-data's boundary generation code (internal to the library, but the sink is wherever new FormData() instances create boundaries for HTTP requests).

Missing Control: The library lacked cryptographically secure random number generation. It relied on a weaker algorithm that could be predicted or brute-forced by attackers with sufficient computational resources or traffic analysis capabilities.

CWE: CWE-330 (Use of Insufficiently Random Values) — this occurs when applications use random values for security purposes but fail to use cryptographically secure randomness sources.

Fix: Upgrade form-data to versions 4.0.6, 3.0.4, or 2.5.4, which implement cryptographically secure random boundary generation using Node.js's crypto module, and update dependent libraries hasown (2.0.4+) and mime-types (2.1.35+).

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

CVE-2025-7783 demonstrates why cryptographic randomness is non-negotiable in security-critical code paths. Multipart form boundaries may seem like a low-level implementation detail, but they're fundamental to the integrity of form submissions. By upgrading to patched versions of form-data and maintaining a disciplined approach to dependency management, you eliminate this attack vector and strengthen your application's security posture.

The lesson extends beyond this specific vulnerability: always use cryptographically secure randomness for security purposes, keep your dependencies updated, and leverage automated security scanning to catch these issues before they reach production.

References

• CWE-330: Use of Insufficiently Random Values
• OWASP: Cryptographic Failures (A02:2021)
• Node.js crypto.randomBytes() Documentation
• Node.js crypto.getRandomValues() Documentation
• Semgrep: Insufficient Randomness Detection
• form-data npm Package
• GitHub PR: fix: upgrade form-data to 2.5.4, 3.0.4, 4.0.4 (CVE-2025-7783)