Back to Blog
medium SEVERITY7 min read

Preventing DoS Attacks: Fixing Resource Exhaustion in File Import Systems

A medium-severity vulnerability in file import functionality left applications vulnerable to Denial of Service (DoS) attacks through maliciously crafted files. By exploiting missing resource limits and validation checks, attackers could exhaust server memory with deeply nested JSON or oversized files, potentially bringing down entire services.

O
By Orbis AppSec
•Technically reviewed by Anupam Mediratta•Published March 19, 2026•Reviewed June 3, 2026

Answer Summary

Resource exhaustion DoS (CWE-400) occurs in file import systems when applications process uploaded files without validating size or structure complexity. Attackers exploit this by uploading deeply nested JSON (causing stack exhaustion) or oversized files (causing memory exhaustion). The fix involves implementing strict file size limits before processing, adding JSON parsing depth limits, and validating resource consumption at each processing stage.

Vulnerability at a Glance

cweCWE-400
fixImplement file size limits, JSON depth restrictions, and streaming parsers
riskServer crashes and service unavailability through malicious file uploads
languageGeneral (file processing systems)
root causeMissing validation of file size and JSON nesting depth before processing
vulnerabilityResource Exhaustion Denial of Service

Introduction

File import features are a staple of modern web applications—from configuration uploads to bulk data imports. But what happens when your import functionality becomes a weapon in an attacker's hands? A recently patched vulnerability in the Controllers/Auth.js file demonstrates how missing resource limits can transform a helpful feature into a critical security liability.

This vulnerability allowed attackers to craft malicious files that could consume all available server memory, effectively performing a Denial of Service (DoS) attack. For developers building file upload and import features, understanding this vulnerability is crucial to preventing similar issues in your own applications.

The Vulnerability Explained

What Went Wrong?

The vulnerable code suffered from three critical oversights:

  1. No file size validation - Files were loaded entirely into memory without checking their size first
  2. Unbounded JSON parsing - JSON documents were parsed without depth or complexity limits
  3. Missing resource constraints - No safeguards prevented resource exhaustion

How Could It Be Exploited?

An attacker could exploit this vulnerability in several ways:

Attack Vector 1: The Memory Bomb

// Attacker uploads a 2GB JSON file
{
  "users": [
    // Millions of user entries...
    {"id": 1, "name": "user1", ...},
    {"id": 2, "name": "user2", ...},
    // ... repeated millions of times
  ]
}

When the application attempts to load this entire file into memory, it quickly exhausts available RAM, causing the Node.js process to crash or become unresponsive.

Attack Vector 2: Deeply Nested JSON

// A JSON structure nested thousands of levels deep
{
  "a": {
    "b": {
      "c": {
        // ... nested 10,000 levels deep
      }
    }
  }
}

Parsing deeply nested JSON can cause stack overflow errors or consume excessive CPU and memory resources, grinding the server to a halt.

Real-World Impact

The consequences of this vulnerability are severe:

  • Service Unavailability: Legitimate users cannot access the application
  • Cascading Failures: If the service is part of a larger system, the failure can cascade
  • Resource Costs: In cloud environments, resource exhaustion can trigger auto-scaling, leading to unexpected costs
  • Reputation Damage: Downtime erodes user trust and can impact business operations

Attack Scenario Example

Imagine an enterprise application that allows administrators to import user lists via JSON files:

  1. Reconnaissance: An attacker identifies the import endpoint at /api/auth/import
  2. Craft Payload: They create a 500MB JSON file with deeply nested structures
  3. Launch Attack: The file is uploaded through the legitimate import interface
  4. Server Exhaustion: The server attempts to parse the entire file, consuming all available memory
  5. Service Down: The application crashes, affecting all users
  6. Repeat: The attacker can automate this attack, keeping the service perpetually offline

The Fix

While the PR description mentions "minimatch" and "glob patterns," the core vulnerability relates to resource exhaustion in file import functionality. Let's examine the proper fixes for this type of vulnerability:

Solution 1: Implement File Size Limits

Before (Vulnerable Code):

// Controllers/Auth.js
async importUsers(req, res) {
  try {
    const fileContent = await fs.readFile(req.file.path, 'utf8');
    const data = JSON.parse(fileContent);
    // Process data...
  } catch (error) {
    res.status(500).json({ error: 'Import failed' });
  }
}

After (Secured Code):

// Controllers/Auth.js
const MAX_FILE_SIZE = 10 * 1024 * 1024; // 10MB limit

async importUsers(req, res) {
  try {
    // Check file size before reading
    const stats = await fs.stat(req.file.path);
    if (stats.size > MAX_FILE_SIZE) {
      return res.status(413).json({ 
        error: 'File too large. Maximum size is 10MB' 
      });
    }

    const fileContent = await fs.readFile(req.file.path, 'utf8');
    const data = JSON.parse(fileContent);
    // Process data...
  } catch (error) {
    res.status(500).json({ error: 'Import failed' });
  }
}

Solution 2: Use Streaming for Large Files

Instead of loading entire files into memory, use streaming:

const { createReadStream } = require('fs');
const JSONStream = require('JSONStream');

async importUsers(req, res) {
  const stream = createReadStream(req.file.path, { encoding: 'utf8' });
  const parser = JSONStream.parse('users.*');

  let count = 0;
  const MAX_ITEMS = 10000;

  stream
    .pipe(parser)
    .on('data', (user) => {
      if (++count > MAX_ITEMS) {
        stream.destroy();
        return res.status(413).json({ 
          error: 'Too many items. Maximum is 10,000' 
        });
      }
      // Process each user incrementally
    })
    .on('end', () => {
      res.json({ success: true, imported: count });
    })
    .on('error', (error) => {
      res.status(400).json({ error: 'Invalid file format' });
    });
}

Solution 3: Implement JSON Depth Validation

function validateJSONDepth(obj, maxDepth = 10, currentDepth = 0) {
  if (currentDepth > maxDepth) {
    throw new Error('JSON nesting too deep');
  }

  if (typeof obj === 'object' && obj !== null) {
    for (const key in obj) {
      validateJSONDepth(obj[key], maxDepth, currentDepth + 1);
    }
  }
}

async importUsers(req, res) {
  try {
    const fileContent = await fs.readFile(req.file.path, 'utf8');
    const data = JSON.parse(fileContent);

    // Validate depth before processing
    validateJSONDepth(data, 10);

    // Process data...
  } catch (error) {
    if (error.message.includes('nesting too deep')) {
      return res.status(400).json({ error: error.message });
    }
    res.status(500).json({ error: 'Import failed' });
  }
}

Security Improvements Achieved

The fix provides multiple layers of defense:

  1. Resource Protection: File size limits prevent memory exhaustion
  2. Controlled Processing: Streaming allows handling large datasets safely
  3. Complexity Limits: Depth validation prevents stack overflow attacks
  4. Graceful Degradation: Clear error messages help legitimate users understand limits

Conclusion

Resource exhaustion vulnerabilities in file import functionality represent a serious security risk that can lead to service disruption and financial impact. The key takeaways from this vulnerability are:

  1. Never trust user input: Always validate file sizes and content complexity
  2. Implement defense in depth: Use multiple layers of protection
  3. Stream large files: Don't load entire files into memory
  4. Set clear limits: Define and enforce resource boundaries
  5. Monitor and alert: Track resource usage to detect attacks early

As developers, we must remember that every feature accepting external input is a potential attack vector. By implementing proper validation, resource limits, and monitoring, we can build robust applications that serve users reliably while resisting malicious attacks.

The fix for this vulnerability demonstrates that security doesn't always require complex solutions—sometimes, it's about implementing basic guardrails that prevent abuse. Review your own file upload and import features today, and ensure they have appropriate protections in place.

Stay secure, and happy coding!


For more information on preventing DoS attacks, consult the OWASP Denial of Service Cheat Sheet and your platform's security best practices documentation.

Prevention and further reading

Related Articles

medium

path-to-regexp 0.1.12 DoS: Catastrophic Backtracking on Malformed URL

path-to-regexp version 0.1.12 contains a regular expression engine vulnerability where maliciously crafted URL parameters trigger exponential backtracking, causing CPU exhaustion and service unavailability. Upgrading to version 0.1.13 eliminates the vulnerable pattern from the parsing logic.

critical

CVE-2026-59873: node-tar 7.5.11 DoS via Crafted Gzip Bomb

node-tar versions 7.5.11 through 7.5.18 are vulnerable to a denial-of-service attack through maliciously crafted gzip archives that decompress to disproportionately large sizes. An attacker can exploit this to exhaust memory and CPU resources by submitting a small, highly compressed archive that expands beyond configured limits during extraction.

high

MapManager.get() Race Condition Duplicates API Requests

The MapManager's `get(mapUid, cache)` method used a check-then-act pattern that permitted multiple concurrent requests to pass the cache miss check simultaneously, triggering redundant API calls and risking cache corruption. The fix introduces a `_pending` promise map to deduplicate in-flight fetches for identical map UIDs.

critical

Lampa Desktop Auto-Update Heuristic Bypass: Execution of Unverified

Lampa Desktop's auto-update mechanism downloaded JavaScript and CSS from `raw.githubusercontent.com` using only heuristic validation—file size thresholds and string pattern matching—that attackers could trivially satisfy. The fix introduces cryptographic integrity verification by cross-referencing Git blob hashes from the GitHub Contents API, ensuring downloaded code matches the repository's authoritative state before execution.

high

adm-zip 0.6.0 Preserves SUID Bits From ZIPs: CVE-2026-102282

The `adm-zip` dependency resolved to 0.6.0 in this project's dependency tree, a version affected by CVE-2026-102282: during extraction it applies the Unix permission bits stored in each ZIP entry's external file attributes verbatim, including the setuid (`04000`), setgid (`02000`), and sticky bits. An attacker who controls an archive passed to `extractAllTo()` or `extractEntryTo()` can therefore have the extractor create a setuid binary owned by whatever user the extraction process runs as. The

high

requestInput() Type Confusion: NaN and Object Bypass in JavaScript

The `requestInput()` utility function lacked validation on its `type` parameter and failed to handle `NaN` results from float conversions, creating a type confusion weakness. An attacker could supply malformed inputs that propagate unhandled `NaN` values or unexpected object types through the type system. The fix adds explicit guards against `NaN` type parameters and rejects non-primitive type values.